Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Pig >> mail # user >> Re: release strategy


Copy link to this message
-
Re: release strategy
+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
>>>
>>
>
>
> --
>
>
>

--