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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-08-24 16:00:33

David Abrahams wrote:
> on Fri Aug 22 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
> 
>> David Abrahams wrote:
>>>>>> 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.
>>>>>
>>>>> It isn't critical since the version number isn't essential until
>>>>> late in the release cycle,
>>>> How does that work?  Does it mean any changes that would be
>>>> inappropriate in a point release will be merged to release at the
>>>> last minute?  I'm still getting used to the new system.
>>> I would really appreciate an answer to this question.  So far, it
>>> looks to me like we either need to decide that as a policy we're
>>> simply not going to do point releases, or we need a separate release
>>> branch for each series (e.g. 1.36.x)
>> Suppose library X has a bug which requires a fix before the next
>> release.  And suppose the fix is tested in the trunk and merged
>> into "release ready" version and the "release ready" version is
>> totally retested.  Wouldn't just assigning a tag (1.36.1) (or "copy)
>> in SVN parlance)  to the current release ready version qualify as a
>> "point release"  That is how would this differ from a "point release"?
>>
>> Maybe I've misunderstood what people mean by "point release".
> 
> A point release is a release that differs minimally from its numeric
> predecessor, with the only changes being bugfixes.  Users that want a
> point release explicitly do *not* want new features, new libraries, or
> other "improvements."  Combine that with the fact that library authors
> may have decided that they need to break backward compatibility in the
> next non-point release, and I don't see how a point release can be spun
> off the "release" branch at arbitrary times.

Good points. It really sounds like it is isn't possible to do point 
releases unless they are regular planned part of the process with their 
own people, testing, reporting, and other resources in place on a 
permanent basis.

> I'm not trying to poke holes in the current release process; I would
> simply like everyone to be very clear about its implications.

Understood. And this discussion is helping to clarify exactly what the 
current release process is and what it isn't.

--Beman