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 Threaded View
Pig >> mail # dev >> Next Pig release proposal


Copy link to this message
-
RE: Next Pig release proposal
I don't see this discussion really converging any time soon and I don't want to see the release delayed by weeks because we can't agree on the label.

I am going to branch as 0.10 tomorrow and keep the proposed schedule unless I hear otherwise.

Olga

-----Original Message-----
From: Thejas Nair [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 25, 2011 10:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Next Pig release proposal

Dmitriy,

I haven't understood how you propose the code in future trunk would get
into 1.x releases, once the 1.0 is out. Will it be possible to meet the
stability criteria that you are applying to 1.0 for all 1.x releases ?

Are you suggesting that all future releases go into a 0.x release before
going into 1.x release ?

-Thejas

On 10/25/11 12:30 AM, Dmitriy Ryaboy wrote:
> 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
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