On 25/09/14 13:21, Henrique de Moraes Holschuh wrote: > 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 > > 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.
AIUI the general rule is that you must merge debian/changelog if and only if you merged the actual changes? In other words, if version A is an ancestor of version B (think about what the graph of branches and merges would look like in gitk or whatever), then version B must have version A's debian/changelog entry somewhere below its own. S -- 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/54241f7a....@debian.org