On Sat, May 3, 2014 at 1:47 PM, Benedikt Ritter <brit...@apache.org> wrote: > no, adding new methods doesn't break compatibility. If you're interested in > this topic [1] is a very good read about it. > > [1] https://wiki.eclipse.org/Evolving_Java-based_APIs >
Thanks for the evolving APIs link. I was actually aware of the fact that adding methods wouldn't break backwards compatibility, but I should have been more specific with my question. What I meant was, does this kind of change (adding public config methods later) count as API breakage in a commons project. As you mentioned, it's no problem for *backwards* compatibility; instead, the potential issue is that two dependencies in a project depend on two different versions of commons-csv, and due to the various magic of maven transitive dependency resolution, the dependency that depends on the older version of commons-csv pulls in its specific version of commons-csv, meaning that the new methods that the other dependency depends on aren't present. Obviously this can be resolved by just specifying the newer (or newest) version of commons-csv in the pom file to avoid worrying about which transitive dependency will be the winner in maven. Anyhow, this was the potential "breakage" that I was inquiring about, but I take it that this isn't something to worry about here. - Gabriel > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
