I think we can keep the versioning convention same and make some minor modifications in release process to make it more like a beta phase - 1. Send the announcement about new release candidate to user mailing list as well. 2. Start the voting process few (5?) days after people have started a chance to try out. Send a reminder about the start of voting after the 'few' days.
I assume, 0.9 release is going to have a jar-withouthadoop as well, which would make it easier for most users to try it out. -Thejas On 6/10/11 1:24 PM, "Alan Gates" <[email protected]> wrote: 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 <[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 >>>> >>> >> >> >> -- >> >> >> --
