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/
