Well,
While I can enjoy the "...and it does it all by itself!" feature of such a setup, I see development and deployment as two very distinct phases, with a lot of QA inbetween.
Nonetheless: having such a repository of packaged "bleeding edge" development can be very useful. E.g. for an automated building infrastructure that is required to build packages against different supported releases and the current development branches. If the current development is available as packages, it is very easy to automatically update the bleeding-edge builders at the beginning of each job.
(ITER is recreating the "nightly" builders as the result of a successful nightly build, which is somewhat close.)
But for any reference, release or production use, I would always insist on developers signing off on what is being packaged. And reasonable version numbers, of course.
Cheers,
~Ralph
Hi Anton,
I would like to share how we generate our (a bit crazy) "FRIB version
numbers" that are automatically generated by our CI server. The
numbering scheme is based on the convention used by Jenkins-Debian Glue
[1,2]:
[...]