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
Given that the majority agrees on option #2, I would suggest to formalize it
and put it in an official document.
Are the bylaws the right place?

This doesn't solve the 1.0(.0) issue but at least we have a clear path
ahead.

Cheers,
--
Gianmarco De Francisci Morales

On Mon, Oct 24, 2011 at 22:12, Olga Natkovich <[EMAIL PROTECTED]> wrote:

> 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
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