On Tue, 11 Nov 2014, Raphael Hertzog wrote: > QUESTION: some people have argued to use debian/master as the latest > packaging targets sometimes sid and sometimes experimental. Should we > standardize on this? Or should we explicitly allow this as an alternative?
Given the feedback received, and the case of derivatives that don't have a stable name for their development releases, I propose to update the "Packaging branches and tags" section with the content below. Does that sound like an improvement? Packaging branches and tags =========================== In general, packaging branches should be named according to the codename of the target distribution. We differentiate however the case of development releases from other releases. For development releases ------------------------ Packages uploaded to the current development release should be prepared in a `<vendor>/master` branch. However, when multiple development releases are regularly used (for example `unstable` and `experimental` in Debian), it is also accepted to name the branches according to the codename or the suite name of the target distribution (aka `debian/sid` or `debian/unstable`, and `debian/experimental`). Those branches can be short-lived (i.e. they exist only until they are merged into `<vendor>/master` or until the version in the associated repository is replaced by the version in `<vendor>/master`) or they can be permanent (in which case `<vendor>/master` should not exist). NOTE: The Git repository listed in debian/control's `Vcs-Git` field should have its HEAD point to the branch where new upstream versions are being packaged (that is one of the branches associated to a development release). The helper tools that do create those repositories should use a command like `git symbolic-ref HEAD refs/heads/debian/master` to update HEAD to point to the desired branch. For stable releases ------------------- When a package targets any release that is not one of the usual development releases (i.e. stable releases or a frozen development release), it should be prepared in a branch named with the codename of the target distribution. In the case of Debian, that means for example `debian/jessie`, `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid "suite" names because those tend to evolve over time ("stable" becomes "oldstable" and so on). Security updates and stable updates are expected to be handled on the branch of the associated distribution. For example, in the case of Debian, uploads to `wheezy-security` or `wheezy-proposed-updates` are prepared on the `debian/wheezy` branch. Shall there be a need to manage different versions of the packages in both repositories, then the branches `debian/wheezy-security` and `debian/wheezy-updates` can be used. Tagging package releases ------------------------ When releasing a Debian package, the packager should create and push a signed tag named `<vendor>/<version>`. For example, a Debian maintainer releasing a package with version 2:1.2~rc1-1 would create a tag named `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should point to the exact commit that was used to build the corresponding upload. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112112021.gk27...@home.ouaza.com