commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Reid <>
Subject Re: [csv] Release planning for commons-csv
Date Fri, 02 May 2014 08:57:11 GMT
Hi Benedikt,

Thanks for the feedback. My comments are inlined below.

On Fri, May 2, 2014 at 9:41 AM, Benedikt Ritter <> wrote:
> 2014-05-02 8:15 GMT+02:00 Gabriel Reid <>:

>> 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.
> 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:
For additional commands, e-mail:

View raw message