Ross Vandegrift <r...@kallisti.us> writes: > Section 4.4 explains quite a bit about debian/changelog, but doesn't > really explain its purpose. I took its purpose to be recording history > and driving automation - which led to some mistakes that might've been > avoided. During a recent thread on mentors [1], I learned that the > purpose is to provide a human readable list of changes between released > versions of Debian. This came as a surprise.
Separate than the point that Policy could probably stand to say something a little more concrete about the purpose of debian/changelog, I suspect this came out of the recurring discussion of whether to include unreleased versions in debian/changelog. It's probably worth noting here that while debian-mentors has converged to a very strong consensus that unreleased versions of packages should not appear in debian/changelog, the consensus about that in the broader project is nowhere near as strong. This is therefore a rule that you pretty much have to follow if you want people to sponsor your uploads, but Debian Developers do not follow it universally. Some people in debian-mentors will make very absolute statements about never including unreleased versions in debian/changelog and always consolidating versions, and will give the impression that literally everyone in Debian holds this view. This is not really the case. It's *most common* to consolidate versions, and usually there's no point in keeping entries for unreleased versions, but this isn't a universal rule followed by every experienced Debian maintainer, and there are times when retaining entries for unreleased versions is useful (there were non-Debian releases of the package, for instance, or there's something about the development path that the maintainer felt was important to document). To include rules about this in Policy would indicate not just that there's a best practice, but that it's also important enough to tell people that they have to follow it. I've always been dubious of this, mostly because I don't see a lot of *harm* in including unreleased versions when the maintainer wants to do that. All the tools cope with this (apt-listchanges shows all the entries, for instance), and so far as I can tell, the primary objection is basically aesthetics. I care as much about aesthetics as the next perfectionist free software developer, but in general I prefer to see a higher bar for inclusion in Policy than aesthetics. As long as variance of practice doesn't *break* anything, I'd generally prefer to keep it out of Policy and in other, more informative guides to best practice, such as the Developer's Reference. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
