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