Then the question is about when/if the compatibility should be broken. https://issues.apache.org/jira/browse/MRUNIT-139 would be quite easy without the history of MRUnit and the @Deprecated....
On Fri, Sep 7, 2012 at 2:19 PM, Dave Beech <d...@paraliatech.com> wrote: > I think this depends on what we decide to do about MRUNIT-138. We were > discussing an incompatible change, and if we do decide to do that I think > the version number should increase to 1.0.0 to reflect this (and also the > fact that this is the first version since graduation). > > If we later go ahead with the API rewrite (MRUNIT-69), this could form > MRUnit 2.0.0! Would line up nicely with Hadoop's own numbering strategy ;) > > On 7 September 2012 07:54, James Kinley <kin...@cloudera.com> wrote: > > > +1 for the 1.0.0 release. I think it's a good idea to increase the major > > version number considering the recent graduation and the included > changes. > > > > On 7 Sep 2012, at 07:29, "Wei, Jianbin" <jianb...@paypal.com> 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
