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 >
