If it is an incompatible change in non-trivial way, I would strong in
favor a 1.0 release.
Regards,
-- Jianbin
On Sep 12, 2012, at 10:01 AM, Brock Noland wrote:
OK, we have the following viewpoints with supporting reasons:
0.10 - supported by a number of people (reasons: none given, 1.0
should be used for Tool interface support)
1.0 - supported by a number of people (reasons: none given, recent
graduation, due to the incompatible change)
I tilt towards the 1.0 release due to the incompatible changes but I
am not strongly committed to that viewpoint. I am strongly committed
to a release whatever the number! :) It would seem easy enough to vote
on the matter but I think votes can become divisive. I have seen that
in the Hadoop community when voting is used to resolve issues it ends
up much like the state of US politics. As such, I'd prefer to settle
this via discussion.
We have all stated our preferences but not our convictions. Is there
anyone who strongly in favor of / opposed to a 0.10 release? Is there
anyone who is strongly in favor of / opposed to a 1.0 release? If so
please state your reasoning.
Brock
On Fri, Sep 7, 2012 at 11:50 AM, Wei, Jianbin
<[email protected]<mailto:
[email protected]>> wrote:
Agree with Dave that when it becomes incompatible, the major version
number should be increased. Major changes also warrant a major number
change.
Regards,
-- Jianbin
On Sep 7, 2012, at 8:06 AM, Brock Noland wrote:
As I understand it, if we implement
https://issues.apache.org/jira/browse/MRUNIT-138 as described in the
JIRA. That is, all the drivers keep state of the inputs, we can
undeprecate the methods depcrecated in
https://issues.apache.org/jira/browse/MRUNIT-64?
Brock
On Fri, Sep 7, 2012 at 7:58 AM, Jim Donofrio <[email protected]
<mailto:[email protected]>> wrote:
I think we need to keep those deprecated methods around for awhile, no
reason to anger users.
On 09/07/2012 08:35 AM, Bertrand Dechoux wrote:
Then the question is about when/if the compatibility should be broken.
https://issues.apache.org/jira/browse/MRUNIT-139 would be quite easy
without the history of MRUnit and the @Deprecated....
On Fri, Sep 7, 2012 at 2:19 PM, Dave Beech <[email protected]<mailto:
[email protected]>> wrote:
I think this depends on what we decide to do about MRUNIT-138. We were
discussing an incompatible change, and if we do decide to do that I
think
the version number should increase to 1.0.0 to reflect this (and also
the
fact that this is the first version since graduation).
If we later go ahead with the API rewrite (MRUNIT-69), this could form
MRUnit 2.0.0! Would line up nicely with Hadoop's own numbering strategy
;)
On 7 September 2012 07:54, James Kinley <[email protected]<mailto:
[email protected]>> wrote:
+1 for the 1.0.0 release. I think it's a good idea to increase the major
version number considering the recent graduation and the included
changes.
On 7 Sep 2012, at 07:29, "Wei, Jianbin" <[email protected]<mailto:
[email protected]>> wrote:
My bad, 0.9.0 --> 0.10.0 is also version increase. My eyes are not
used
to have a 2 digits minor version yet. However, I still prefer a
one-digit
minor version as most software do that in practice.
Regards,
-- Jianbin
On Sep 6, 2012, at 10:41 PM, Bertrand Dechoux wrote:
I am not sure to understand "It is not good to backtracking version.".
Does it mean that the version after graduating should show the 'step'?
Is that a common way to do it?
Not taking into account the graduation, I would also favor the "0.10.0"
instead of "1.0.0".
Regards
Bertrand
--
Apache MRUnit - Unit testing MapReduce -
http://incubator.apache.org/mrunit/
--
Apache MRUnit - Unit testing MapReduce -
http://incubator.apache.org/mrunit/
