You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@mrunit.apache.org by Brock Noland <br...@cloudera.com> on 2012/09/06 21:09:49 UTC

1.0.0 Release

I'd like to get a release out there this month. There is a ton of fixes:

https://issues.apache.org/jira/browse/MRUNIT/fixforversion/12320548#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel

and of course the API is changing to allow multiple input key/values.
If you want to see something in the 1.0.0 release, please speak up.

Brock

-- 
Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

I will have the release instructions updated tomorrow and then Dave is
spinning the RC so it would be on his timeline.

On Thu, Sep 27, 2012 at 9:01 AM, Jim Donofrio <do...@gmail.com> 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 <da...@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 <da...@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 <do...@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 <db...@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 <ja...@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
>>>>>>>>>>>>> <do...@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
>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>>>> jianbwei@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
>>>>>>>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>>>>>>>> dave@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
>>>>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>>>>>>>> kinley@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"
>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Dave Beech <da...@paraliatech.com>.

Thanks Brock. I'll have a look at what we'd need to do to use the
maven release plugin. I have used it before and I do like it.

I will also go through the open JIRAs today and make sure there are no
others that should be marked as blockers before this next release.

Cheers
Dave

On 28 September 2012 19:40, Brock Noland <br...@cloudera.com> wrote:
> Good call on all accounts!
>
> 1) I like the release plugin idea, just don't know anything about it.
>
> 2) I removed the incubator references and updated the site for SVN
> deploy. Here http://www.apache.org/dev/release.html under "How do I
> upload a release (newer way)?" describes the new deployment method.
>
> Brock
>
> On Fri, Sep 28, 2012 at 1:02 PM, Bertrand Dechoux <de...@gmail.com> wrote:
>> 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 <br...@cloudera.com> 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 <ki...@cloudera.com> 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 <da...@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 <da...@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 <
>>> donofrio111@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 <db...@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 <
>>> jarcec@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 <
>>> brock@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 <
>>> donofrio111@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 <
>>> jianbwei@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
>>> >>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>> >>>>>>>>>>>>>>>>>> jianbwei@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
>>> >>>>>>>>>>>>>>>>>> <donofrio111@gmail.com
>>> >>>>>>>>>>>>>>>>>> <ma...@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
>>> >>>>>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>> >>>>>>>>>>>>>>>>>> dave@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
>>> >>>>>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>> >>>>>>>>>>>>>>>>>> kinley@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"
>>> >>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>> >>>>>>>>>>>>>>>>>> jianbwei@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/
>>>
>>
>>
>>
>> --
>> Bertrand Dechoux
>
>
>
> --
> Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

Good call on all accounts!

1) I like the release plugin idea, just don't know anything about it.

2) I removed the incubator references and updated the site for SVN
deploy. Here http://www.apache.org/dev/release.html under "How do I
upload a release (newer way)?" describes the new deployment method.

Brock

On Fri, Sep 28, 2012 at 1:02 PM, Bertrand Dechoux <de...@gmail.com> wrote:
> 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 <br...@cloudera.com> 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 <ki...@cloudera.com> 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 <da...@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 <da...@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 <
>> donofrio111@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 <db...@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 <
>> jarcec@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 <
>> brock@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 <
>> donofrio111@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 <
>> jianbwei@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
>> >>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>> >>>>>>>>>>>>>>>>>> jianbwei@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
>> >>>>>>>>>>>>>>>>>> <donofrio111@gmail.com
>> >>>>>>>>>>>>>>>>>> <ma...@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
>> >>>>>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>> >>>>>>>>>>>>>>>>>> dave@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
>> >>>>>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>> >>>>>>>>>>>>>>>>>> kinley@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"
>> >>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>> >>>>>>>>>>>>>>>>>> jianbwei@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/
>>
>
>
>
> --
> Bertrand Dechoux



-- 
Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/

Re: 1.0.0 Release

Posted by Bertrand Dechoux <de...@gmail.com>.

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 <br...@cloudera.com> 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 <ki...@cloudera.com> 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 <da...@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 <da...@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 <
> donofrio111@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 <db...@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 <
> jarcec@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 <
> brock@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 <
> donofrio111@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 <
> jianbwei@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
> >>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
> >>>>>>>>>>>>>>>>>> jianbwei@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
> >>>>>>>>>>>>>>>>>> <donofrio111@gmail.com
> >>>>>>>>>>>>>>>>>> <ma...@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
> >>>>>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
> >>>>>>>>>>>>>>>>>> dave@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
> >>>>>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
> >>>>>>>>>>>>>>>>>> kinley@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"
> >>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
> >>>>>>>>>>>>>>>>>> jianbwei@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/
>



-- 
Bertrand Dechoux

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <ki...@cloudera.com> 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 <da...@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 <da...@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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>>>>> jianbwei@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
>>>>>>>>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>>>>>>>>> dave@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
>>>>>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>>>>>>>>> kinley@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"
>>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by James Kinley <ki...@cloudera.com>.

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 <da...@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 <da...@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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>>>> jianbwei@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
>>>>>>>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>>>>>>>> dave@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
>>>>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>>>>>>>> kinley@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"
>>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>>>> jianbwei@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/
>> 
>> 
>

Re: 1.0.0 Release

Posted by Jim Donofrio <do...@gmail.com>.

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 <da...@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 <da...@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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>>> jianbwei@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
>>>>>>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>>>>>>> dave@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
>>>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>>>>>>> kinley@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"
>>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>>> jianbwei@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/
>
>

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <da...@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 <da...@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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>> jianbwei@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
>>>>>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>>>>>> dave@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
>>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>>>>>> kinley@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"
>>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Dave Beech <da...@paraliatech.com>.

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 <da...@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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>> jianbwei@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
>>>>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>>>>> dave@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
>>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>>>>> kinley@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"
>>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <da...@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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>> jianbwei@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
>>>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>>>> dave@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
>>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>>>> kinley@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"
>>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <da...@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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>> jianbwei@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
>>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>>> dave@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
>>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>>> kinley@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"
>>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Dave Beech <da...@paraliatech.com>.

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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>> jianbwei@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
>>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>>> <ma...@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
>>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>>> dave@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
>>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>>> kinley@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"
>>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <do...@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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>> jianbwei@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
>>>>>>>>>> <donofrio111@gmail.com
>>>>>>>>>> <ma...@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
>>>>>>>>>> <dave@paraliatech.com<mailto:
>>>>>>>>>> dave@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
>>>>>>>>>> <kinley@cloudera.com<mailto:
>>>>>>>>>> kinley@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"
>>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Jim Donofrio <do...@gmail.com>.

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 <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>>> jianbwei@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 <donofrio111@gmail.com
>>>>>>>>> <ma...@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 <dave@paraliatech.com<mailto:
>>>>>>>>> dave@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 <kinley@cloudera.com<mailto:
>>>>>>>>> kinley@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" <jianbwei@paypal.com<mailto:
>>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by James Kinley <ki...@cloudera.com>.

+1 to major release with MRUNIT-138.

James.

On 24 Sep 2012, at 09:21, Dave Beech <db...@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 <ja...@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 <do...@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 <ji...@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
>>>>>>>> <jianbwei@paypal.com<mailto:
>>>>>>>> jianbwei@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 <donofrio111@gmail.com
>>>>>>>> <ma...@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 <dave@paraliatech.com<mailto:
>>>>>>>> dave@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 <kinley@cloudera.com<mailto:
>>>>>>>> kinley@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" <jianbwei@paypal.com<mailto:
>>>>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Dave Beech <db...@apache.org>.

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 <ja...@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 <do...@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 <ji...@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
>> >>>>> <jianbwei@paypal.com<mailto:
>> >>>>> jianbwei@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 <donofrio111@gmail.com
>> >>>>> <ma...@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 <dave@paraliatech.com<mailto:
>> >>>>> dave@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 <kinley@cloudera.com<mailto:
>> >>>>> kinley@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" <jianbwei@paypal.com<mailto:
>> >>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Jarek Jarcec Cecho <ja...@apache.org>.

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 <do...@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 <ji...@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
> >>>>> <jianbwei@paypal.com<mailto:
> >>>>> jianbwei@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 <donofrio111@gmail.com
> >>>>> <ma...@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 <dave@paraliatech.com<mailto:
> >>>>> dave@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 <kinley@cloudera.com<mailto:
> >>>>> kinley@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" <jianbwei@paypal.com<mailto:
> >>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <do...@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 <ji...@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
>>>>> <jianbwei@paypal.com<mailto:
>>>>> jianbwei@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 <donofrio111@gmail.com
>>>>> <ma...@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 <dave@paraliatech.com<mailto:
>>>>> dave@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 <kinley@cloudera.com<mailto:
>>>>> kinley@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" <jianbwei@paypal.com<mailto:
>>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <do...@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 <ji...@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
>>>> <jianbwei@paypal.com<mailto:
>>>> jianbwei@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 <donofrio111@gmail.com
>>>> <ma...@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 <dave@paraliatech.com<mailto:
>>>> dave@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 <kinley@cloudera.com<mailto:
>>>> kinley@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" <jianbwei@paypal.com<mailto:
>>>> jianbwei@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/

Re: 1.0.0 Release

Posted by Jim Donofrio <do...@gmail.com>.

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 <ji...@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 <jianbwei@paypal.com<mailto:
>>> jianbwei@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 <donofrio111@gmail.com
>>> <ma...@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 <dave@paraliatech.com<mailto:
>>> dave@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 <kinley@cloudera.com<mailto:
>>> kinley@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" <jianbwei@paypal.com<mailto:
>>> jianbwei@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

Re: 1.0.0 Release

Posted by Jarek Jarcec Cecho <ja...@apache.org>.

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 <ji...@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 <jianbwei@paypal.com<mailto:
> > jianbwei@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 <donofrio111@gmail.com
> > <ma...@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 <dave@paraliatech.com<mailto:
> > dave@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 <kinley@cloudera.com<mailto:
> > kinley@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" <jianbwei@paypal.com<mailto:
> > jianbwei@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

Re: 1.0.0 Release

Posted by Bertrand Dechoux <de...@gmail.com>.

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 <ji...@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 <jianbwei@paypal.com<mailto:
> jianbwei@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 <donofrio111@gmail.com
> <ma...@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 <dave@paraliatech.com<mailto:
> dave@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 <kinley@cloudera.com<mailto:
> kinley@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" <jianbwei@paypal.com<mailto:
> jianbwei@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

Re: 1.0.0 Release

Posted by "Wei, Jianbin" <ji...@paypal.com>.

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 <ji...@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 <do...@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 <da...@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 <ki...@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" <ji...@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/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <ji...@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 <do...@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 <da...@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 <ki...@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" <ji...@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/

Re: 1.0.0 Release

Posted by "Wei, Jianbin" <ji...@paypal.com>.

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:

Brock

On Fri, Sep 7, 2012 at 7:58 AM, Jim Donofrio <do...@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 <da...@paraliatech.com> wrote:

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 <ki...@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" <ji...@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/

Re: 1.0.0 Release

Posted by Brock Noland <br...@cloudera.com>.

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 <do...@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 <da...@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 <ki...@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" <ji...@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/

Re: 1.0.0 Release

Posted by Jim Donofrio <do...@gmail.com>.

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 <da...@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 <ki...@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" <ji...@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
>>>>
>
>

Re: 1.0.0 Release

Posted by Bertrand Dechoux <de...@gmail.com>.

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 <da...@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 <ki...@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" <ji...@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
> > >
> >
>



-- 
Bertrand Dechoux

Re: 1.0.0 Release

Posted by Dave Beech <da...@paraliatech.com>.

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 <ki...@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" <ji...@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
> >
>

Re: 1.0.0 Release

Posted by James Kinley <ki...@cloudera.com>.

+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" <ji...@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
>

Re: 1.0.0 Release

Posted by "Wei, Jianbin" <ji...@paypal.com>.

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

Re: 1.0.0 Release

Posted by Bertrand Dechoux <de...@gmail.com>.

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

On Fri, Sep 7, 2012 at 7:30 AM, Jarek Jarcec Cecho <ja...@apache.org>wrote:

> I would personally support the idea to have next version to be "0.10.0"
> instead of "1.0.0".
>
> Jarcec
>
> On Fri, Sep 07, 2012 at 03:42:28AM +0000, Wei, Jianbin wrote:
> > It is not good to backtracking version.  There is 0.9 out already,
> although it is incubating.
> >
> > Thanks,
> >
> > Jianbin
> >
> > On Sep 6, 2012, at 17:50, "Jim Donofrio" <do...@gmail.com> wrote:
> >
> > > I agree but not sure this release should be 1.0.0, I would make it
> 0.10.0. I think we wait till there is support for a regular Tool Driver
> class for 1.0.0.
> > >
> > > On 09/06/2012 03:09 PM, Brock Noland wrote:
> > >> I'd like to get a release out there this month. There is a ton of
> fixes:
> > >>
> > >>
> https://issues.apache.org/jira/browse/MRUNIT/fixforversion/12320548#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
> > >>
> > >> and of course the API is changing to allow multiple input key/values.
> > >> If you want to see something in the 1.0.0 release, please speak up.
> > >>
> > >> Brock
> > >>
> > >
>



-- 
Bertrand Dechoux

Re: 1.0.0 Release

Posted by Jarek Jarcec Cecho <ja...@apache.org>.

I would personally support the idea to have next version to be "0.10.0" instead of "1.0.0".

Jarcec

On Fri, Sep 07, 2012 at 03:42:28AM +0000, Wei, Jianbin wrote:
> It is not good to backtracking version.  There is 0.9 out already, although it is incubating.
> 
> Thanks,
> 
> Jianbin
> 
> On Sep 6, 2012, at 17:50, "Jim Donofrio" <do...@gmail.com> wrote:
> 
> > I agree but not sure this release should be 1.0.0, I would make it 0.10.0. I think we wait till there is support for a regular Tool Driver class for 1.0.0.
> > 
> > On 09/06/2012 03:09 PM, Brock Noland wrote:
> >> I'd like to get a release out there this month. There is a ton of fixes:
> >> 
> >> https://issues.apache.org/jira/browse/MRUNIT/fixforversion/12320548#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
> >> 
> >> and of course the API is changing to allow multiple input key/values.
> >> If you want to see something in the 1.0.0 release, please speak up.
> >> 
> >> Brock
> >> 
> >

Re: 1.0.0 Release

Posted by "Wei, Jianbin" <ji...@paypal.com>.

It is not good to backtracking version.  There is 0.9 out already, although it is incubating.

Thanks,

Jianbin

On Sep 6, 2012, at 17:50, "Jim Donofrio" <do...@gmail.com> wrote:

> I agree but not sure this release should be 1.0.0, I would make it 0.10.0. I think we wait till there is support for a regular Tool Driver class for 1.0.0.
> 
> On 09/06/2012 03:09 PM, Brock Noland wrote:
>> I'd like to get a release out there this month. There is a ton of fixes:
>> 
>> https://issues.apache.org/jira/browse/MRUNIT/fixforversion/12320548#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
>> 
>> and of course the API is changing to allow multiple input key/values.
>> If you want to see something in the 1.0.0 release, please speak up.
>> 
>> Brock
>> 
>

Re: 1.0.0 Release

Posted by Jim Donofrio <do...@gmail.com>.

I agree but not sure this release should be 1.0.0, I would make it 
0.10.0. I think we wait till there is support for a regular Tool Driver 
class for 1.0.0.

On 09/06/2012 03:09 PM, Brock Noland wrote:
> I'd like to get a release out there this month. There is a ton of fixes:
>
> https://issues.apache.org/jira/browse/MRUNIT/fixforversion/12320548#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
>
> and of course the API is changing to allow multiple input key/values.
> If you want to see something in the 1.0.0 release, please speak up.
>
> Brock
>