API breakage would be 2.0.  Do we know yet that fixing those issue would
send use to 2.0?

Thanks

-D


On Fri, May 2, 2014 at 11:02 AM, Gary Gregory <garydgreg...@gmail.com>wrote:

> 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
>

Reply via email to