+1 for calling it rc, as an alternative to beta. -Thejas
On 6/7/11 1:19 PM, "Dmitriy Ryaboy" <[email protected]> wrote: I think the tendency has been to call initial release candidates just that, RCs. Why not package up rc0, have people play with it, if no one finds anything critical, make a release, and do dot-releases if critical stuff comes up later. D On Tue, Jun 7, 2011 at 12:24 PM, Thejas M Nair <[email protected]> wrote: > The release cycle of most of the popular softwares (including open source > ones) has a public beta phase. The beta term is well understood by people > and will set the right expectations (compared to just saying Oless stable > that previous *.0 releases'). > > If we can clearly state the guidelines for calling a release beta vs ga , I > think we can avoid having too much debate each time over calling the release > beta vs ga. > How about this criteria for calling a release beta ? - The first release of > new version of pig (0.x) will be a beta. Once a beta release has been > around for a minimum of two weeks, and all known regressions have been > fixed, the next minor release with the fixes will be called ga. > > -Thejas > > > > > > The version number could be 0.9.0, but in the release notes and download > pages, I think we should > > > On 6/6/11 4:25 PM, "Alan Gates" <[email protected]> wrote: > >> I like 0.9.0 over beta. The code has undergone a lot of testing, just not as >> much as previous x.0 releases. My other concern is that in the future we may >> end up with beta2 and beta3 releases, and with arguments about whether a >> given >> release is a beta or ga, and what makes a release beta bs ga (the definition >> can't be that Yahoo has tested it). Sticking to a numbering scheme seems >> cleaner. >> >> Alan. >> >> Sent from my iPhone >> >> On Jun 3, 2011, at 8:08, Thejas M Nair <[email protected]> wrote: >> >>> >>> >>> >>> On 6/2/11 2:09 PM, "Olga Natkovich" <[email protected]> wrote: >>> >>>> Hi, >>> >>>> seemed to make most sense to the group. This rule would be combined with >>>> another one - that no features or non-P1 bug fixes would be allowed after >>>> the >>>> branch is cut to guarantee branch stability. >>>> >>> >>> Clarifying for sake users who are not familiar with pig release process - A >>> new svn branch is created when a new version of pig, when the code freeze >>> happens. New features and non-P1 bugs continue to get committed to trunk >>> after that. >>> >>>> We would need to clearly state that this release is likely to be less >>>> stable >>>> than previous .0 releases (especially given the amount of change that went >>>> in.). Once we get sufficient number of bug fixes, we would call for 0.9.1 >>>> release which would be similar in stability to our earlier .0 release. This >>> >>> I think it is better to explicitly call the initial release a beta release. >>> Ie 0.9.beta . Around 4 weeks after the beta release, we can have a vote for >>> the stable release. >>> >>> -Thejas >>> >> > > > -- > > > --
