commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [csv] Release planning for commons-csv
Date Fri, 02 May 2014 14:02:13 GMT
+1 to keep the discussion going with or without patches. We need to get a
1.0 out the door.


On Fri, May 2, 2014 at 4:57 AM, Gabriel Reid <> wrote:

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

E-Mail: |
Java Persistence with Hibernate, Second Edition<>
JUnit in Action, Second Edition <>
Spring Batch in Action <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message