+1 to major release with MRUNIT-138. James.
On 24 Sep 2012, at 09:21, Dave Beech <[email protected]> wrote: > Hi Brock > Same here - I would be happy to see a major version release with > MRUNIT-138 included. > Cheers > Dave > > On 24 September 2012 07:35, Jarek Jarcec Cecho <[email protected]> wrote: >> Hi Brock, >> thank you for your summary. I'm fine with the idea and I won't -1 it. >> >> Jarcec >> >> On Sat, Sep 22, 2012 at 07:48:16AM -0500, Brock Noland wrote: >>> It feels like we approaching a consensus on that if we include >>> MRUNIT-138, which is backwards incompatible but an improved user API, >>> we should bump the major version. Assuming MRUNIT-138 is included, is >>> there anyone that would -1 a release with the 1.0 designation? >>> >>> Brock >>> >>> On Thu, Sep 13, 2012 at 11:42 AM, Brock Noland <[email protected]> wrote: >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>>>> 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 >>>>>>>> <[email protected]<mailto: >>>>>>>> [email protected]>> 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 <[email protected] >>>>>>>> <mailto:[email protected]>> 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 >>>>>>>> <[email protected]<mailto: >>>>>>>> [email protected]>> 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 <[email protected]<mailto: >>>>>>>> [email protected]>> 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" <[email protected]<mailto: >>>>>>>> [email protected]>> 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/ >>> >>> >>> >>> -- >>> Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
