I guess it has maybe already been tried but the maven release plugin is good. But I wouldn't have now the time to verify if all the steps could be done that way. Maybe for a future release?
One trivial mistake : Put in a Infrastructure JIRA <https://issues.apache.org/jira/browse/INFRA> asking to get added to the incubator unix group on people.apache.org and the mrunit deployer roler for Nexus I guess the 'incubator' is not needed even though I have never opened an infrastructure JIRA so I don't know if there is a different unix group for graduated projects. Regards Bertrand On Fri, Sep 28, 2012 at 7:30 PM, Brock Noland <[email protected]> wrote: > OK, I have updated the release documents. > http://mrunit.apache.org/pmc/how_to_release.html > > I think that should be correct, but anyone with a little git knowledge > might want to double check. > > Brock > > On Thu, Sep 27, 2012 at 5:36 PM, James Kinley <[email protected]> wrote: > > I can probably take a look at 111 next week, but I wouldn't want it to > hold up Dave with the release. > > > > Thanks, James. > > > > On 27 Sep 2012, at 15:01, Jim Donofrio wrote: > > > >> When did you hope to cut a release candidate? > >> > >> We also need to go through the open tickets to see what can wait, Brock > has MRUNIT-136 as a blocker. Sorry for not contributing in awhile but I > need to fix some javadoc for 101,114,115. It would also be nice if someone > did 111 for this release because we really should be using the release > plugin, makes the whole process a lot easier. > >> > >> On 09/26/2012 11:45 AM, Brock Noland wrote: > >>> OK that seems like a bargain! :) I'll work on updating the > >>> instructions to what I think they should be (based on the experience > >>> of the last few releases). > >>> > >>> Thanks! > >>> Brock > >>> > >>> On Wed, Sep 26, 2012 at 10:42 AM, Dave Beech <[email protected]> > wrote: > >>>> The instructions also mention "incubator" quite heavily. I'd be happy > >>>> to do the release (but only if the instructions get fixed first!!) > >>>> > >>>> On 26 September 2012 16:39, Brock Noland <[email protected]> wrote: > >>>>> 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/ > >>> > >>> > >> > > > > > > -- > Apache MRUnit - Unit testing MapReduce - > http://incubator.apache.org/mrunit/ > -- Bertrand Dechoux
