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
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,
>>> 1.1.1 etc for bug fixes.
>>>
>>> I personally prefer scheme 2, increasing major version too frequently
>>> might
>>> be confusing to users. How's other folks feel?
>>>
>>> Daniel
>>>
>>>
>>> On Sat, Oct 22, 2011 at 2:31 AM, Gianmarco De Francisci Morales<
>>> [EMAIL PROTECTED]>  wrote:
>>>
>>>> Hi,
>>>>
>>>> just my 2 cents.
>>>>
>>>> I think the issue here is not 1.0 vs 0.10, but what's the versioning
>>> scheme
>>>> we want to use for Pig.
>>>> Up to now it has been just an increasing number after a '0.' prefix,
>>>> changed
>>>> when the community felt it was time. I think this works well for a small
>>>> project, but it is somewhat fuzzy.
>>>>
>>>> I like the idea of having<major>.<minor>.<patch>  versions like many
>>> other
>>>> projects. It's a very clear and almost standard way of versioning a
>>> piece
>>>> of
>>>> software. It has clear rules on when to change each of the numbers, and
>>>> lets
>>>> the user get an idea of backward compatibility at a glance.
>>>>
>>>> So, to conclude, I am in favor of going 1.0 (or 1.0.0) as long as we
>>> decide
>>>> a clear versioning policy (whichever it is).
>>>> So that the 1.0 milestone would mark the beginning of our new policy.
>>>>
>>>> Cheers,
>>>> --
>>>> Gianmarco
>>>>
>>>>
>>>>
>>>> On Fri, Oct 21, 2011 at 23:10,<[EMAIL PROTECTED]>  wrote:
>>>>
>>>>> If one were to rewrite input and output formats to use the webhdfs://
>>>>> APIs, this would not be an issue, right ?
>>>>>
>>>>> - milind
>>>>>
>>>>>
>>>>> On 10/21/11 1:50 PM, "Santhosh Srinivasan"<[EMAIL PROTECTED]>  wrote:
>>>>>
>>>>>> If I was not clear in my earlier email, I apologize for the lack of
>>>>>> clarity. I am no longer in favour of waiting for Hadoop API stability