bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Version 2.4.2.


From: Joel E. Denny
Subject: Re: [PATCH] Version 2.4.2.
Date: Sat, 20 Mar 2010 18:40:09 -0400 (EDT)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]