OK great, it sounds like the release is on! Does anyone want to be the Release Manager? I am more than willing to be the RM if no one else is interested, but as I have done it a few time times I won't feel too bad if someone else wants to. ;)
Brock On Mon, Sep 24, 2012 at 7:28 AM, Jim Donofrio <[email protected]> wrote: > I wont -1 it but I wont +1 it either. I would rather save major revision > changes for more drastic api changes but we need to cut this release so I > wont get in the way. Lets cut a release candidate on Oct 1 as we talked > about before. > > > On 09/24/2012 04:55 AM, James Kinley wrote: >> >> +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/ > > -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
