Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


+
Olga Natkovich 2011-10-20, 23:40
+
Santhosh Srinivasan 2011-10-20, 23:58
+
Thejas Nair 2011-10-21, 17:45
+
Santhosh Srinivasan 2011-10-21, 17:59
+
Thejas Nair 2011-10-21, 18:22
+
Santhosh Srinivasan 2011-10-21, 20:50
+
Milind.Bhandarkar@... 2011-10-21, 21:10
+
Gianmarco De Francisci Mo... 2011-10-22, 09:31
+
Daniel Dai 2011-10-24, 18:59
+
Dmitriy Ryaboy 2011-10-24, 19:43
+
Thejas Nair 2011-10-24, 19:55
+
Dmitriy Ryaboy 2011-10-24, 21:32
+
Thejas Nair 2011-10-25, 16:54
+
Dmitriy Ryaboy 2011-10-25, 00:38
+
Olga Natkovich 2011-10-25, 00:54
+
Thejas Nair 2011-10-25, 01:10
+
Dmitriy Ryaboy 2011-10-25, 01:45
+
Santhosh Srinivasan 2011-10-25, 06:53
+
Dmitriy Ryaboy 2011-10-25, 07:30
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?

Santhosh

-----Original Message-----
From: Dmitriy Ryaboy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 25, 2011 12:31 AM
To: [EMAIL PROTECTED]
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
> To: [EMAIL PROTECTED]
> 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,
+
Thejas Nair 2011-10-25, 17:01
+
Olga Natkovich 2011-10-25, 17:37
+
Olga Natkovich 2011-10-24, 20:12
+
Scott Carey 2011-10-24, 23:05
+
Gianmarco De Francisci Mo... 2011-10-25, 09:22
+
Alan Gates 2011-10-21, 18:00
+
Olga Natkovich 2011-10-25, 00:51
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB