Hi Akim, On Sat, 20 Mar 2010, Akim Demaille wrote:
> > It bothers me that branch-2.5:ChangeLog and master:ChangeLog now have an > > entry that says "Version 2.4.2" but that is more recent than many > > ChangeLog entries that do not appear in release 2.4.2. What's the normal > > way of handling this? > > First, congratulations! Thanks. > Second, I understand your concern, but I'm not sure there is any > clearcut answer here. I guess that now that people know that even time > is relative, it can also have branches :) :) Ok, it sounds like I'm not breaking any obvious norm here, so I'll just leave it as it is. It makes sense that a release's ChangeLog accurately documents the change history for that release but not necessarily for earlier releases. However, NEWS accurately reflects all earlier releases.... But that raises another question for NEWS. If Bison ends up like gcc and has multiple release series concurrently, the order of releases might be: 2.4.2, 2.5, 2.4.3, 2.5.1. Do we sort by version number or release date in NEWS? I'm thinking 2.4.3's NEWS would omit 2.5 because 2.5 is a higher version number, but 2.5.1's NEWS would include 2.4.3 and sort on version number not date. I think that's what's going on in GCC's 4.4.1's NEWS. Also, when it's time for 2.5 candidates, I think I'll switch to a scheme something like 2.5-candidate-1 and 2.5-candidate-2. 2.4.2a and 2.4.2b wouldn't make sense here because there could potentially be a 2.4.3 later. What do you think?
