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 <jar...@apache.org> 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 <br...@cloudera.com> 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 <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/ >> >> >> >> -- >> Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
