commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [csv] Release planning for commons-csv
Date Fri, 02 May 2014 17:00:12 GMT
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 <garydgregory@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.reid@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 <britter@apache.org>
> > wrote:
> > > 2014-05-02 8:15 GMT+02:00 Gabriel Reid <gabriel.reid@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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

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