On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote: > On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles <[EMAIL PROTECTED]> > 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 · [EMAIL PROTECTED] 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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )