We are currently looking for a workflow to manage Ubuntu packages and releases within apt repositories. Until now our small team did the development in git. One occasionally used the master branch to create builds that are then packaged manually (into Ubuntu .deb) via dpkg-buildpackage and deployed by single apt repository.

What we would like to have instead are separate repositories, i.e. an "unstable" repository used for development only, a "testing" repository and finally a "stable" repository. Obviously, customers should get updates from the "stable" repository only. Ideally packages are moved from "unstable" to "testing" to "stable" in our development cycle without requiring that packages need to be rebuilt or re-packaged. We are targeting Ubuntu but need build and deploy packages suited for several Ubuntu like 'precise' or 'trusty'.

This raises a few questions:

  1. How to manage the version numbers to keep the update path straight-forward?

    To us it is important that version numbers are correct in the sense that a higher version number actually means "newer than". However, during development one may need to create many packages from different sources that are deployed via the "unstable" repository. For each new package the apt-get update should install the newest package. Simply increasing the version number would mean that every developer in our team must be aware of the current version number. Worse, the version must be consistent across multiple git feature branches which seems difficult to me.

  2. Do we need additional repositories, i.e. one per developer to avoid version number conflicts during testing? Do we need constructs like appending "ppa" suffixes to the version number? Or is there a different approach?


You must log in to answer this question.

Browse other questions tagged .