On changelogs and version tracking
 

Recently a bug that was brought to my attention[1] told me that I
should remind everyone about the importance of ordering of changelogs
in their package for the purposes of version control in the BTS.

Be careful when you reorder or add back changelog entries. If you
return to a previous version by means of an epoch (or something else)
you can either just tack the new upload/version at the top of the
changelog or elide the other entries in the changelog, and continue on
as before. Changelog entries should always be in upload order (which
presumably corresponds to chronological order) with the version upon
which this upload is based on immediately preceeding it.

If you don't do this, you end up with interesting version graphs like
[2].[3]

As always, if you have any questions about the impact of changelog
order on the version tree or other similar questions, feel free to ask
on debian-debbug@lists.debian.org or ask in #debbugs (OFTC) or ping me
(dondelelcaro) or any other debbugs person on IRC.


Don Armstrong

1: #403645, but it doesn't really matter
2: http://tiny.cc/E3heI
3: I should note that it's no big deal to fix these sorts of problems
up post-facto; it's just moderately confusing. ;-)
--
Americans can always be counted on to do the right thing, after they
have exhausted all other possibilities.
-- W. Churchill

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On changelogs and version tracking
 

Don Armstrong <don@debian.org> wrote:
[...]
> Be careful when you reorder or add back changelog entries. If you
> return to a previous version by means of an epoch (or something else)
> you can either just tack the new upload/version at the top of the
> changelog or elide the other entries in the changelog, and continue on
> as before. Changelog entries should always be in upload order (which
> presumably corresponds to chronological order) with the version upon
> which this upload is based on immediately preceeding it.
[...]

What is the proper way to merge branches?

When upstream branches off a new development version I sometimes do
they same in Debian, uploading upstream's development version to
experimental while keeping stable in sid. Once upstream makes a major
release I make an upload, based on the code in experimental.

Obviously I do not want to lose either experimental or sid changelog
entries.

Sorting cronologically seems to be wrong, since experimental and sid
entries would get mixed up, therefore I go for sorting by debian
version numbers. Is this broken?
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org