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

Switch to Threaded View
Pig >> mail # dev >> Next Pig release proposal

Copy link to this message
RE: Next Pig release proposal
Fair enough. Now its boiling down to ...

Which release should be promoted to 1.0?
What are the stability related concerns/bugs that need to be addressed before we promote the last release to 1.0?


-----Original Message-----
From: Dmitriy Ryaboy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 25, 2011 12:31 AM
Subject: Re: Next Pig release proposal

Thanks Santhosh, you understood my meaning precisely.

I believe that unlike other releases, 1.0 is "special" in people's
minds, it's a "we are ready" label. I don't think we should promote
trunk, even in gloriously stable future, to 1.0, for the same reason I
don't think we should promote the current trunk to 1.0 (but would be
ok with, say, promoting 9.2...) -- our 1.0 release should be stable,
and trunk is not by nature, even when we make a release off it. I
would prefer we not tie our hands in search of stability and avoid
adding new features / refactors / etc in trunk because it's got the
1.0 label hanging over it. We already have a history of policing what
goes into dot-dot releases (8.1, 9.1), and I think those have been
working well for creating more stable releases while we can do more
radical stuff on trunk.

On Mon, Oct 24, 2011 at 11:53 PM, Santhosh Srinivasan <[EMAIL PROTECTED]> wrote:
> My understanding of Dmitriy's proposal is as follows:
> 1. We need to establish (more) stability before we transition to 1.0
> 2. Assuming that we have satisfied the constraints in point #1 and that we are calling the next release 0.10.0, we could have the following situation:
>        i. Trunk
>        ii. 0.11.0 branch
>        iii. 0.10.0 branch
>        iv. 0.9.X branch
> 3. The next release on trunk will be 1.2
> 4. The next dot release on the 0.11.0 branch will be  1.1, the next dot release on 0.10.0 will be 1.0, etc.
> I am with Dmitriy on the first two points. For the latter two points, I would approach it as follows:
> 1. The next release on trunk will 1.0
> 2. The 0.11.0 dot releases will continue with 0.11.1, 0.11.2, etc., 0.10.0 dot releases will continue with 0.10.1, 0.10.2, etc.
> 3. All subsequent releases based off of trunk and the 1.0 branch will bear the 1.X.Y signature till we hit the next major release
> Santhosh
> -----Original Message-----
> From: Dmitriy Ryaboy [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 24, 2011 6:46 PM
> Subject: Re: Next Pig release proposal
> I am just saying based on what's in trunk, 10.0 should not be 1.0. I am not sure alphas and betas will work cause people just won't install them...
> Olga -- my diagramming skills leave something to be desired :). I was just saying we let 0.10 stabilize (via a few dot releases), then move all versions up in one fell swoop -- so 0.10 line becomes 1.0, 0.11 becomes 1.1, and if at that point 0.12 also exists, it becomes 1.2.
> D
> On Mon, Oct 24, 2011 at 6:10 PM, Thejas Nair <[EMAIL PROTECTED]> wrote:
>> Dmitriy,
>> I think what you are saying is something similar to alpha/beta releases.
>> (maybe beta1, beta2 .. is better).
>> So the first release could be 1.0.0_beta1. I scheme will be easier for
>> users to understand.
>> But I am not sure what the criteria for promoting a release from betaX
>> to general release should be.
>> Thanks,
>> Thejas
>> On 10/24/11 5:38 PM, Dmitriy Ryaboy wrote:
>>> To be a little more concrete about what I am saying here -- I don't
>>> think we should put a "1.0" label on any *.0 release. 0.8.1 is pretty
>>> solid; 0.9.0 has some holes, 0.9.1 is better. If we put 1.0 on what
>>> is currently being thought of as 0.10, it will have some stability /
>>> usability issues (things tend to show up after we make a release and
>>> people in the wild start trying it), and those issues will make a
>>> poor impression on those who expect 1.0 to be shiny and polished
>>> after so much time. I'm in favor of waiting a couple of dot releases,
>>> promoting a stabilized release into 1.0, and going from there. So,