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
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.


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.


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
>> --