1.33.0 Release, why not Beta it first?
I am going to once again raise the issue of putting the releases into Beta, prior to making a final (6-9 month) release. 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. Just my opinion, Mike
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. -- Aleksey Gurtovoy MetaCommunications Engineering
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
participants (3)
-
Aleksey Gurtovoy -
Beman Dawes -
Michael Goldshteyn