Unless I hear any objections, I am going to start the release process as 0.9.0 shortly. Please, avoid any checkins to the 0.9 branch for now.
Thanks, Olga -----Original Message----- From: Alan Gates [mailto:ga...@yahoo-inc.com] Sent: Friday, June 10, 2011 1:24 PM To: u...@pig.apache.org Subject: Re: release strategy Isn't this what we already do? Are you just suggesting a longer vote period? We want to have 0.9.whateverwecallit out by the summit. Alan. On Jun 7, 2011, at 1:19 PM, Dmitriy Ryaboy 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 <te...@yahoo-inc.com> > 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" <alanfga...@gmail.com> 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 <te...@yahoo-inc.com> wrote: >>> >>>> >>>> >>>> >>>> On 6/2/11 2:09 PM, "Olga Natkovich" <ol...@yahoo-inc.com> 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 >>>> >>> >> >> >> -- >> >> >>
