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 <d...@paraliatech.com> 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 <br...@cloudera.com> 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 <br...@cloudera.com> 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 <d...@paraliatech.com> 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 <br...@cloudera.com> 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 <donofrio...@gmail.com> >>>>> 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 <dbe...@apache.org> 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 <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/ >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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/
