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
Santhosh Srinivasan 2011-10-25, 06:53
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,
>> pictorially:
>>
>> -- trunk --- 0.11-dev ----------0.12-dev------------**------| 1.2-dev!
>>     \               \
>>      \               \ ---------------- 0.11.0 --------------------|
>> 1.1.0!
>>       \
>>        \------- 0.10.0 ------- 0.10.1 ------- 0.10.2 --------| 1.0.0 !!
>>
>> On Mon, Oct 24, 2011 at 12:43 PM, Dmitriy Ryaboy<[EMAIL PROTECTED]>
>>  wrote:
>>
>>  I am good with Scheme 2.
>>>
>>> We are finding a fair number of issues trying to move from Pig 0.8.1
>>> to 0.9, and I don't think those issues are fixed in 10, either.. not
>>> sure that this "stabilization" process has happened yet.
>>>
>>> D
>>>
>>>
>>> On Mon, Oct 24, 2011 at 11:59 AM, Daniel
>>> Dai<[EMAIL PROTECTED]>**
>>> wrote:
>>>
>>>  Yes, we need a versioning scheme. There are two versioning scheme I
>>> can
>>>> think of:
>>>>
>>>> Scheme 1:
>>>> <major>.<patch>
>>>> <major>  will be the feature rich release every 3 month <patch>  
>>>> will be the bug fix release when necessary
>>>>
>>>> Nov release will be 1.0, Feb release will be 2.0. There will be
>>>> 1.1, 2.1 etc for bug fixes.
>>>>
>>>> Scheme 2:
>>>> <major>.<minor>.<patch>
>>>> Most of our 3 month release will be counted as<minor>  release
>>>> unless there are major user facing/disruptive changes.
>>>>
>>>> Nov release will be 1.0.0, Feb release will be 1.1.0. There will be
>>>> 1.0.1,