[Top][All Lists]
[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?