Re: RFC: DEP-14: Recommended layout for Git packaging repositories
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/
Reply to: