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
I am also is in favor of #2 and assumed that's the way we go:

(1) Major version change: major disruptive or non-backward compatible changes
(2) Minor version changes: small features + bug fixes; *no breakage of backward compatibility*
(3) Patch version changes: P1 bug fixes; no new features, no compatibility breakage.

Olga

-----Original Message-----
From: Daniel Dai [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 24, 2011 12:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Next Pig release proposal

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
> > >across Hadoop versions. It's a pipe dream.
> > >
> > >When we had PigInputFormat and PigOutputFormat, your reasoning would be
> > >spot on. I am concerned about the following. Our tight integration with
> > >Hadoop due to the use of Input and Output format might lead to a break
> in
> > >backward compatibility. I am not sure if the comparison with that of
> Java
> > >is valid. Probably a majority of the users don't use JNI. Its very hard
> > >to use Pig without writing custom load and store functions. The default
> > >load and store don't suffice for a majority of use cases that I have
> > >observed.
> > >
> > >I am trying to get all factors that might influence this decision. From
> > >the few emails that have been exchanged since yesterday, we have the
> > >following factors:
> > >
> > >1. Hadoop 0.20.205 (support for Append)
> > >2. Hadoop 0.22
> > >3. Hadoop 0.23
> > >4. Maturity of the new parser
> > >5. Stability of the new logical plan
> > >6. Other components in the eco system.
> > >       - Avro (1.5.4, 1.4.1, ...)
> > >       - Cassandra (1.0.0, 0.8.7, ...)
> > >       - Chukwa (0.4.0, 0.3.0, ...)
> > >       - Hama (0.3.0, 0.2.0, ...)
> > >       - Hbase (0.90.4, 0.90.3, 0.90.2, 0.90.1, ...)
> > >       - Hive (Releases - 0.7.1, 0.7.0, 0.6.0, ...)
> > >       - Zookeeper (3.3.3, 3.3.2, 3.2.2, 3.1.2, ...)
> > >
> > >Santhosh
> > >
> > >
> > >-----Original Message--