Hello Gabriel, no, adding new methods doesn't break compatibility. If you're interested in this topic [1] is a very good read about it.
Regards, Benedikt [1] https://wiki.eclipse.org/Evolving_Java-based_APIs 2014-05-03 10:22 GMT+02:00 Gabriel Reid <gabriel.r...@gmail.com>: > From what I've seen of the discussion on the two issues, the > near-worst-case scenario is the addition of a couple of new configuration > methods, thus not breaking backwards compatibility on the API. Does that > count as API breakage? > > > > On 02 May 2014, at 20:48, Dan Tran <dant...@gmail.com> wrote: > > > > API breakage would be 2.0. Do we know yet that fixing those issue would > > send use to 2.0? > > > > Thanks > > > > -D > > > > > > On Fri, May 2, 2014 at 11:02 AM, Gary Gregory <garydgreg...@gmail.com > >wrote: > > > >> The question is would fixing these two issues break compatibility? We > have > >> three compatibility levels: binary, source, and behavior. > >> > >> I'm guessing we would be ok on source and binary. Would the behavior be > >> different enough to mean the version that fixes these should be 2.0? I'm > >> guessing no. > >> > >> Thoughs? Comments? > >> > >> Gary > >> > >> <div>-------- Original message --------</div><div>From: Benedikt Ritter > < > >> brit...@apache.org> </div><div>Date:05/02/2014 13:00 (GMT-05:00) > >> </div><div>To: Commons Developers List <dev@commons.apache.org> > >> </div><div>Subject: Re: [csv] Release planning for commons-csv > </div><div> > >> </div>So you're saying we should release 1.0 from the current trunk? I > >> would > >> volunteer to RM. > >> > >> > >> 2014-05-02 16:02 GMT+02:00 Gary Gregory <garydgreg...@gmail.com>: > >> > >>> +1 to keep the discussion going with or without patches. We need to > get a > >>> 1.0 out the door. > >>> > >>> Gary > >>> > >>> > >>> On Fri, May 2, 2014 at 4:57 AM, Gabriel Reid <gabriel.r...@gmail.com> > >>> wrote: > >>> > >>>> Hi Benedikt, > >>>> > >>>> Thanks for the feedback. My comments are inlined below. > >>>> > >>>> On Fri, May 2, 2014 at 9:41 AM, Benedikt Ritter <brit...@apache.org> > >>>> wrote: > >>>>> 2014-05-02 8:15 GMT+02:00 Gabriel Reid <gabriel.r...@gmail.com>: > >>>> > >>>>>> If there are open issues that are specifically standing in the way > >> of > >>>>>> a release, I would be happy to assist in attempting to resolve them > >> if > >>>>>> someone can point me in the right direction. > >>>>> we are close to a release for a long time now. However we are still > >>>> looking > >>>>> for a solution to CSV-35 [1] and CSV-58 [2]. There have been long > >>>>> discussions around this issues and to me it looks like there still is > >>> no > >>>>> solution. If you have a smart idea feel free to create a patch. > >>>> > >>>> Thanks for pointing these out. I'll certainly take a look at them in > >>>> greater detail to see if there's anything I can see or think of. > >>>> > >>>>> At commons we are crazy about binary compatibility ;-) We're going > >>>> through > >>>>> a lot a trouble to make sure you won't run into jar hell when using > >> our > >>>>> components. This is why you can use commons lang 2.6 alongside > >> commons > >>>> lang > >>>>> 3.3.2 in the same class path. To achieve this, we change the maven > >>>>> coordinates as well as the package coordinates when we break binary > >>>>> compatibility. > >>>> [snip] > >>>>> > >>>>> The problem is, even if we declare this release as an alpha release > >> or > >>>> what > >>>>> ever, people will start using it. And all of a sudden you have > >>>> commons-csv > >>>>> 0.1 in your class path through transitive dependencies but you really > >>>> need > >>>>> 1.0 which isn't compatible. You're app has been broken by a rushed > >> out > >>>>> release with an unstable API... > >>>> > >>>> Understood, and I certainly think that worry about binary > >>>> compatibility is a worthy cause (and certainly don't want to try to > >>>> convince the project to go against that principle). However, I think > >>>> that there are some additional things to consider here as well. > >>>> > >>>> Both of the blocking issues are over two years old, with very little > >>>> activity in the past 6 months. There are currently people making use > >>>> of commons-csv by doing things like copying the code into their own > >>>> repo, or making their own release build. These are the same users who > >>>> are intended to be protected by the promise of binary compatibility, > >>>> but they (and projects that make use of their published artifacts) > >>>> will suffer from the same consequences that you outlined by breaking > >>>> binary incompatibility. > >>>> > >>>> The argument could of course be made that people shouldn't be doing > >>>> things like making their own build or folding the commons-csv code > >>>> into their own projects, but the fact is that people are doing this > >>>> (just like people will use a 0.1 release, despite any kinds of > >>>> warnings about possible future incompatibilites). > >>>> > >>>> Additionally, the two issues in question are both classified as bugs, > >>>> and it appears that both will (or at least could be) eventually be > >>>> resolved by adding additional configuration methods. This addition of > >>>> additional configuration methods won't break backwards compatibility. > >>>> > >>>> Basically my points are: > >>>> * by delaying a release to protect users, the same users are doing > >>>> things which bring the same (or even worse) risks that the delayed > >>>> release is supposed to be protecting them from > >>>> * it appears to be possible to resolve the two blocking issues in the > >>>> future without breaking binary compatibility > >>>> > >>>> - Gabriel > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >>> -- > >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >>> Java Persistence with Hibernate, Second Edition< > >>> http://www.manning.com/bauer3/> > >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > >>> Spring Batch in Action <http://www.manning.com/templier/> > >>> Blog: http://garygregory.wordpress.com > >>> Home: http://garygregory.com/ > >>> Tweet! http://twitter.com/GaryGregory > >> > >> > >> > >> -- > >> http://people.apache.org/~britter/ > >> http://www.systemoutprintln.de/ > >> http://twitter.com/BenediktRitter > >> http://github.com/britter > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
