[Zope-dev] Extend specification of how to maintain the changelog

[Christian Theune]

On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote:
> On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles <ccomb at free.fr> wrote:
> > The risk is that people will think the bug is fixed in 3.6.0 and not in the
> > 3.5 branch.
> 
> That's a general documentation risk, and I don't think anyone else has
> come up with a better way to deal with this.  If you can find an
> example that solves this without excess burden on the maintainers,
> that would be really good to hear about.

The problem here is in managing the release notes in a single file within
version control is easy to do.

Everything else that makes this more clear either requires tedious manual
tasks or really hard automation.

Additionally, if you're bound to a branch, I guess it would be really easy to
see what's changed there -- the release notes of that branch will tell you.

The issue is that providing a 'correct' flat view of a tree structure is
really hard in this case. The version numbering does not imply a time line!

Even when merging all the release notes, one would see the same change appear
in 3.5.3, 3.6.4 and 3.7.0 eventually. Now, as you would read it from top to
bottom, you might also think that it wasn't fixed in 3.5, even if you look
there. (Agreed, the lookup would be much simpler.)

I guess that merging release notes automatically would actually be easier in
the format that I proposed ...

Christian


-- 
Christian Theune · ct at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1
Zope and Plone consulting and development