-Re: release strategy
Thejas M Nair 2011-06-03, 15:08
On 6/2/11 2:09 PM, "Olga Natkovich" <[EMAIL PROTECTED]> wrote:
> 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
> 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.