Re: Branching changelogs or not
Andreas Tille <andreas@an3as.eu> writes:
> [Reply-To set to debian-devel]
>
> Hi,
>
> on the Debian Med list a discussion about handling changelogs was started[1]
> which addressed the following questions:
>
> 1. What to do with pre-Debian-Release changelogs (if packaging
> needed some time and went through several intermediate steps
> before it was uploaded to ftp.d.o (with the special case of
> releases in other distros).
> There was the conclusion to basically keep this changelog
> entries.
My opinion here is that it depends. There are basically 2 cases:
1) local developement builds that don't leave the house
I often compile several versions of a package till I'm satisfied.
Sometimes I ask others to test them but in a verry controlled
enviroment. The package isn't spread. None the less it helps to bump the
version for every build to keep them straight when discussing errors.
But when releasing the final version for upload all those intermediate
versions are best collapsed into one changelog entry. No need to mention
all the in-house, so to speak, testing.
2) intermittant versions that the public might get hold of
If I upload a version to e.g. mentors it becomes public. If the sponsor
then finds some bug in the upload, usualy days later, I tend to bump the
version and keep the changelog entry. People might have grabed it from
mentors and installed it and still have it installed weeks or month
later. They might also report bugs on it. If the intermittant versions
are removed from the changelog the version tracking in the BTS can't
work.
On the other hand this means the sponsor has to include multiple
changelog entries in the changes file (important for closing bugs). So
it is a balaning act.
MfG
Goswin
Reply to: