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 -- 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/20140925122100.gc10...@khazad-dum.debian.net
