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

Switch to Threaded View
Pig >> mail # dev >> release strategy


Copy link to this message
-
RE: release strategy
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:[EMAIL PROTECTED]]
Sent: Friday, June 10, 2011 1:24 PM
To: [EMAIL PROTECTED]
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 <[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
>>>>
>>>
>>
>>
>> --
>>
>>
>>