On Sat, May 3, 2014 at 1:47 PM, Benedikt Ritter <brit...@apache.org> wrote:
> no, adding new methods doesn't break compatibility. If you're interested in
> this topic [1] is a very good read about it.
>
> [1] https://wiki.eclipse.org/Evolving_Java-based_APIs
>

Thanks for the evolving APIs link. I was actually aware of the fact
that adding methods wouldn't break backwards compatibility, but I
should have been more specific with my question. What I meant was,
does this kind of change (adding public config methods later) count as
API breakage in a commons project.

As you mentioned, it's no problem for *backwards* compatibility;
instead, the potential issue is that two dependencies in a project
depend on two different versions of commons-csv, and due to the
various magic of maven transitive dependency resolution, the
dependency that depends on the older version of commons-csv pulls in
its specific version of commons-csv, meaning that the new methods that
the other dependency depends on aren't present. Obviously this can be
resolved by just specifying the newer (or newest) version of
commons-csv in the pom file to avoid worrying about which transitive
dependency will be the winner in maven. Anyhow, this was the potential
"breakage" that I was inquiring about, but I take it that this isn't
something to worry about here.

- Gabriel

>
> 2014-05-03 10:22 GMT+02:00 Gabriel Reid <gabriel.r...@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 <dant...@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 <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
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to