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 Sat, 03 May 2014 11:47:30 GMT
Hello Gabriel,

no, adding new methods doesn't break compatibility. If you're interested in
this topic [1] is a very good read about it.

Regards,
Benedikt

[1] https://wiki.eclipse.org/Evolving_Java-based_APIs


2014-05-03 10:22 GMT+02:00 Gabriel Reid <gabriel.reid@gmail.com>:

> From what I've seen of the discussion on the two issues, the
> near-worst-case scenario is the addition of a couple of new configuration
> methods, thus not breaking backwards compatibility on the API. Does that
> count as API breakage?
>
>
> > On 02 May 2014, at 20:48, Dan Tran <dantran@gmail.com> wrote:
> >
> > 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 <garydgregory@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
> <
> >> britter@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 <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
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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