Re: versions / suffixes in experimental
On Thu, 25 Sep 2014, Simon McVittie wrote:
> Approach 1, which is (IMO) better when the changes you are making in
> experimental are truly experimental, like enabling features or patches
> whose medium-term future you're not sure about:
>
> 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experimental
> 2.2.5-6 to unstable
Keep in mind the BTS version tracking requirements, which translate into
requirements for which past package changelog entries must be included in
debian/changelog as well.
When there is a continuity in the bug-tracking sense between 2.2.5-5~exp1
and 2.2.5-6~exp1, regardless of what your workflow is, 2.2.5-6~exp1's
debian/changelog must include a merge of 2.2.5-5~exp1's debian/changelog and
2.2.5-6's debian/changelog.
Otherwise, as soon as 2.2.5-6~exp1 gets installed in experimental, the BTS
will think any bugs against 2.2.5-5~exp1 are on a different branch, and will
not consider these closed by the 2.2.5-6~exp1 upload.
It is also important to use the correct -vVERSION flag in dpkg-genchanges,
to make sure the correct debian/changelog entries will go in the .changes
file for the upload. This is well explained in the debian-backports
guidelines, but it applies to uploads to *any* suite (experimental,
stable-proposed-updates, stable-security, backports, etc).
For example: in the experimental upload above, you'd need to call
dpkg-buildpackage -v2.2.5-5~exp1 (or pbuilder --debbuildopts
"-v2.2.5-5~exp1", etc) when preparing the 2.2.5-6~exp1 upload, which will
get passed down to dpkg-genchanges by debhelper.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: