Re: [boost] [next release] Any new libraries ready for the next release?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-08-18 04:19:48

On Mon, Aug 18, 2008 at 4:01 PM, Nicola Musatti
<Nicola.Musatti_at_[hidden]> 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.