r324 - /web/deps/dep14.mdwn

Mon Jul 6 13:21:34 UTC 2015

Author: hertzog
Date: Mon Jul  6 13:21:34 2015
New Revision: 324

URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=324
Log:
Recommend <vendor>/master but allow <vendor>/<codename> for development releases

Modified:
    web/deps/dep14.mdwn

Modified: web/deps/dep14.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep14.mdwn?rev=324&op=diff
==============================================================================

--- web/deps/dep14.mdwn	(original)
+++ web/deps/dep14.mdwn	Mon Jul  6 13:21:34 2015
@@ -66,25 +66,54 @@
 Packaging branches and tags
 ===========================
 
-Packaging branches should be named according to the codename of the
+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/sid`, `debian/jessie`, `debian/experimental`,
-`debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid
-"suite" names because those tend to evolve over time ("stable" becomes
-"oldstable" and so on).
-
-The Git repository listed in debian/control's `Vcs-Git` field should
-usually have its HEAD point to the branch corresponding to the
-distribution where new upstream versions are usually sent. For Debian,
-it will usually be `debian/sid` (or sometimes `debian/experimental`).
-
-  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?
-
-The helper tools that do create those repositories should use a command
-like `git symbolic-ref HEAD refs/heads/debian/sid` to update HEAD
-to point to the desired branch.
+`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


