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
>

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

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

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

--

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

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