I suppose this will be the first release using git so the instructions will have to be updated...
On Wed, Sep 26, 2012 at 10:37 AM, Brock Noland <[email protected]> wrote: > Hi, > > It's not a ton of work once you have done it, but the first time it > can take some time. > > 1) Making sure we have the changes we said we would have in this release > a) This release was contingent on a JIRA > b) Ensuring the FIXED IN field in JIRA is correct > 2) Executing the instructions here > http://mrunit.apache.org/pmc/how_to_release.html > > Since we are a smaller project #1 is pretty easy. For projects like > Hadoop #1 is a huge undertaking. For us, the real work is setting up > your GPG keys and getting maven to deploy the jars correctly. > Everything outside of environmental conditions *should* be documented > in the release page. > > Since we are doing an incompatible change, we want to make sure the > release notes reflect this. We also typically write a blog article > (https://blogs.apache.org/mrunit/) and then ask Cloudera to re-post. > In the past this has been about publicity for the project but this > time it's probably a little more important due to the incompatibility. > > Brock > > On Wed, Sep 26, 2012 at 10:20 AM, Dave Beech <[email protected]> wrote: >> Hi Brock - what's involved? I'm relatively new to the Apache process >> but am willing to give it a go. >> >> Cheers, >> Dave >> >> On 26 September 2012 16:18, Brock Noland <[email protected]> wrote: >>> 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/ > > > > -- > Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/ -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
