Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Pig >> mail # dev >> Next Pig release proposal


+
Olga Natkovich 2011-10-20, 23:40
+
Santhosh Srinivasan 2011-10-20, 23:58
+
Thejas Nair 2011-10-21, 17:45
+
Santhosh Srinivasan 2011-10-21, 17:59
+
Thejas Nair 2011-10-21, 18:22
+
Santhosh Srinivasan 2011-10-21, 20:50
+
Milind.Bhandarkar@... 2011-10-21, 21:10
+
Gianmarco De Francisci Mo... 2011-10-22, 09:31
+
Daniel Dai 2011-10-24, 18:59
+
Dmitriy Ryaboy 2011-10-24, 19:43
+
Thejas Nair 2011-10-24, 19:55
+
Dmitriy Ryaboy 2011-10-24, 21:32
+
Thejas Nair 2011-10-25, 16:54
+
Dmitriy Ryaboy 2011-10-25, 00:38
+
Olga Natkovich 2011-10-25, 00:54
+
Thejas Nair 2011-10-25, 01:10
+
Dmitriy Ryaboy 2011-10-25, 01:45
+
Santhosh Srinivasan 2011-10-25, 06:53
+
Dmitriy Ryaboy 2011-10-25, 07:30
+
Santhosh Srinivasan 2011-10-25, 07:52
+
Thejas Nair 2011-10-25, 17:01
+
Olga Natkovich 2011-10-25, 17:37
+
Olga Natkovich 2011-10-24, 20:12
+
Scott Carey 2011-10-24, 23:05
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
+
Alan Gates 2011-10-21, 18:00
+
Olga Natkovich 2011-10-25, 00:51