I agree that the changes in this release are not nearly as substantial as handling the Tool interface but I do they are major improvements. For example, we now allow users to specify many input key/values and have distributed cache support. For quick reference: http://s.apache.org/NQY
Brock On Thu, Sep 13, 2012 at 8:16 AM, Jim Donofrio <donofrio...@gmail.com> wrote: > Yes graduation has nothing to do with the quality or state of the code, > graduation is all about community and should not influence a release number. > > I agree that 1.0 would signal a breaking change but 1.0 should also signal > major improvements, api changes, new features. I dont think this release > contains any drastic features. I think we should continue in the 0.* > versions for awhile until we add major new features such as Tool support. At > that time you can change the package names to org.apache.mrunit and go to > 1.0. I would rather not become like Firefox or Chrome and do major release > number changes on every release. > > > On 09/13/2012 06:31 AM, Jarek Jarcec Cecho wrote: >> >> 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 > > -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
