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
