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 >
