On Mon, Aug 18, 2008 at 4:01 PM, Nicola Musatti <Nicola.Musatti@gmail.com> wrote:
Beman Dawes <bdawes <at> acm.org> writes:
Eric Niebler wrote:
Beman Dawes wrote:
Will any new libraries be ready to go in the next release?
I'm hoping to get proto in. Why do you ask?
To determine if the next release is 1.37.0 or 1.36.1, so I can bump the version number.
Wouldn't it be better to keep the minor release numbers for strictly bug-fix, no major API/ABI change type of releases? In my opinion the middle number should always be bumped for planned, quarterly releases. If at one round there is little to add it makes it a good opportunity to compensate in delays from previous releases and to tune the release procedure.
I would agree here. But more to this, for example for people who have standardized on Boost 1.35 for example already, shifting to 1.36 is sometimes just too much to ask to get bug fixes that ought to have been in 1.35.1 -- and besides, it's only been how many months between 1.35 and 1.36 : what happens when people find bugs in 1.35 that aren't fixed in 1.36, does that mean the fix will have to be available in 1.37? I understand that it's a lot harder to maintain multiple versions of libraries especially since changes to libraries are the responsibility of library authors/maintainers. Back-porting (critical) fixes for example from 1.36 to certain libraries in 1.35 to yield 1.35.1 might be a more viable option for users that want to stick with 1.35 while waiting for new libraries in 1.36 to "mature". This introduces some burden to the release manager (if Beman would be the same release manager that will manage a 1.35.1 release) but it also allows for an opportunity to others who would want to try their hand at making a point-release. Having a group of people for example dedicated to back-porting fixes from later releases (or from trunk perhaps) into a bugfix release (which can go out more frequently than a quarterly release, say a bugfix release every week if there are things to push out) for particular release numbers (a team for 1.35, another for 1.36) increases the involvement of those interested and perhaps encourages more contribution from non-authors/maintainers. I don't know though if this is welcome, but I think it's worth a shot.
It would be great if resources were available to issue bug-fix releases regularly, say as gcc does. As it is bug-fix releases are only issued when they are perceived as inevitable, and a place in the numbering scheme should be kept aside for those.
I don't see value in a regular bug-fix release especially if there aren't any bug fixes to push. Unless you're back-porting patches from later releases of existing libraries on a regular basis, then maybe that would be worth a shot. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.