Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-22 21:29:20


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.

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

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk