I do have similar reasoning here: 1.0 - in case that we're breaking backward compatibility 0.10 - in case that we're not breaking backward compatibility
I personally do not see graduation of the project important enough for the version to jump to next major. We've recently graduated sqoop and flume and remained on the same major version without any issues. But I'll support next reason no matter the final version. Jarcec On Wed, Sep 12, 2012 at 11:41:08PM +0200, Bertrand Dechoux wrote: > And I would say the same in a reverse way. > If we do a 1.0 release, all required incompatible changes should be done so > that there would be no need to drag unneeded deprecated stuff from the 1.0 > up to the 2.0. > > For me, the question is whether we should break compatibility for the next > release. If yes, then break all which is necessary for a clean future. If > not, then assure full compatibility. If yes, it should be 1.0. If not, it > should be 0.10. > > The following question is then : if we keep compatibility what will the > next release ship with? Is a release worth the new features/bug fixes? On > that point, I am not knowledgeable enough to answer. I would accept the > decisions of the more 'ancient' devs. But it should indeed be discussed. > > Regards, > > Bertrand > > > > > > On Wed, Sep 12, 2012 at 9:05 PM, Wei, Jianbin <jianb...@paypal.com> wrote: > > > If it is an incompatible change in non-trivial way, I would strong in > > favor a 1.0 release. > > > > Regards, > > > > -- Jianbin > > > > On Sep 12, 2012, at 10:01 AM, Brock Noland wrote: > > > > OK, we have the following viewpoints with supporting reasons: > > > > 0.10 - supported by a number of people (reasons: none given, 1.0 > > should be used for Tool interface support) > > 1.0 - supported by a number of people (reasons: none given, recent > > graduation, due to the incompatible change) > > > > I tilt towards the 1.0 release due to the incompatible changes but I > > am not strongly committed to that viewpoint. I am strongly committed > > to a release whatever the number! :) It would seem easy enough to vote > > on the matter but I think votes can become divisive. I have seen that > > in the Hadoop community when voting is used to resolve issues it ends > > up much like the state of US politics. As such, I'd prefer to settle > > this via discussion. > > > > We have all stated our preferences but not our convictions. Is there > > anyone who strongly in favor of / opposed to a 0.10 release? Is there > > anyone who is strongly in favor of / opposed to a 1.0 release? If so > > please state your reasoning. > > > > Brock > > > > On Fri, Sep 7, 2012 at 11:50 AM, Wei, Jianbin <jianb...@paypal.com<mailto: > > jianb...@paypal.com>> wrote: > > Agree with Dave that when it becomes incompatible, the major version > > number should be increased. Major changes also warrant a major number > > change. > > > > Regards, > > > > -- Jianbin > > > > On Sep 7, 2012, at 8:06 AM, Brock Noland wrote: > > > > As I understand it, if we implement > > https://issues.apache.org/jira/browse/MRUNIT-138 as described in the > > JIRA. That is, all the drivers keep state of the inputs, we can > > undeprecate the methods depcrecated in > > https://issues.apache.org/jira/browse/MRUNIT-64? > > > > Brock > > > > On Fri, Sep 7, 2012 at 7:58 AM, Jim Donofrio <donofrio...@gmail.com > > <mailto:donofrio...@gmail.com>> wrote: > > I think we need to keep those deprecated methods around for awhile, no > > reason to anger users. > > > > > > On 09/07/2012 08:35 AM, Bertrand Dechoux wrote: > > > > Then the question is about when/if the compatibility should be broken. > > > > https://issues.apache.org/jira/browse/MRUNIT-139 would be quite easy > > without the history of MRUnit and the @Deprecated.... > > > > On Fri, Sep 7, 2012 at 2:19 PM, Dave Beech <d...@paraliatech.com<mailto: > > d...@paraliatech.com>> wrote: > > > > I think this depends on what we decide to do about MRUNIT-138. We were > > discussing an incompatible change, and if we do decide to do that I think > > the version number should increase to 1.0.0 to reflect this (and also the > > fact that this is the first version since graduation). > > > > If we later go ahead with the API rewrite (MRUNIT-69), this could form > > MRUnit 2.0.0! Would line up nicely with Hadoop's own numbering strategy > > ;) > > > > On 7 September 2012 07:54, James Kinley <kin...@cloudera.com<mailto: > > kin...@cloudera.com>> wrote: > > > > +1 for the 1.0.0 release. I think it's a good idea to increase the major > > version number considering the recent graduation and the included > > > > changes. > > > > On 7 Sep 2012, at 07:29, "Wei, Jianbin" <jianb...@paypal.com<mailto: > > jianb...@paypal.com>> wrote: > > > > My bad, 0.9.0 --> 0.10.0 is also version increase. My eyes are not > > > > used > > > > to have a 2 digits minor version yet. However, I still prefer a > > > > one-digit > > > > minor version as most software do that in practice. > > > > Regards, > > > > -- Jianbin > > > > On Sep 6, 2012, at 10:41 PM, Bertrand Dechoux wrote: > > > > I am not sure to understand "It is not good to backtracking version.". > > Does it mean that the version after graduating should show the 'step'? > > Is that a common way to do it? > > > > Not taking into account the graduation, I would also favor the "0.10.0" > > instead of "1.0.0". > > > > Regards > > > > Bertrand > > > > > > > > > > > > > > > > -- > > Apache MRUnit - Unit testing MapReduce - > > http://incubator.apache.org/mrunit/ > > > > > > > > > > -- > > Apache MRUnit - Unit testing MapReduce - > > http://incubator.apache.org/mrunit/ > > > > > > > -- > Bertrand Dechoux
signature.asc
Description: Digital signature
