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
