Re: [boost] 1.33.0 Release, why not Beta it first?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-08-02 08:17:51

At 08:52 AM 8/2/2005, Aleksey Gurtovoy wrote:
 >Michael Goldshteyn writes:
 >> I am going to once again raise the issue of putting the releases into
 >Beta,
 >> prior to making a final (6-9 month) release.
 >
 >There is always a beta period before the draft tarballs get released,
 >the question is, how long should it be and what kind of fixes are
 >acceptable during that period and what are not.
 >
 >FWIW (and IIRC), in 1.32 it took us three iterations and about a week
 >to sort out the final glitches.
 >
 >> Perhaps we need a policy of the
 >> release being in a final Beta built form for some period, say 2-4 
weeks,
 >> prior to the final release. I think this will allow people who wait for 
a
 >
 >> packaged version to experiment with any newly added features, fixes,
 >etc...
 >> and report issues that can be resolved in the final release, but were 
not
 >
 >> made visible by the regression tests.
 >
 >That's a sound idea (to prolong a beta period, that is), but the
 >details need to be proposed and decided upon -- in particular, some
 >formal criteria for starting beta stage and bug fixes during it need
 >to be formulated and clearly spelled out. Otherwise people will wait
 >until the beta tarballs are available to start testing on their
 >platforms and submit bugs/patches only to find the release manager
 >reject them.

I agree with Michael and Aleksey, but I don't really think of it as a beta 
period. More like a release candidate review period.

How about a two-week RC-review period, with a policy that documentation and 
web site fixes are OK without prior approval, but code fixes have to be 
approved by the release manager?

The point being we are essentially done, but would like to detect and avoid 
"showstoppers".

--Beman