commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: [DISCUSS] API compatibility policy
Date Tue, 08 Oct 2013 21:00:15 GMT
A good resource if you didn't know it existed:
http://commons.apache.org/releases/versioning.html


On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory <garydgregory@gmail.com> wrote:

> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> <siegfried.goeschl@it20one.at> wrote:
> > That's a reasonable style of versioning :)
> >
> > I had many issues with binary compatibilty with a commons-email release
> due to changing the return value from void to a this reference plus some
> moving of constants. You basically end up with either many restrictions or
> creating major releases
>
> Then just create major releases! ;) Why would you not want to provide
> BC? Why add to the jar hell problem? I, the developer, have no control
> over how the API I provide will be used and distributed...
>
> G
>
> >
> > Cheers,
> >
> > Siegfried Goeschl
> >
> >> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tcurdt@vafer.org>:
> >>
> >> Cannot remember which component from the top of my head - but it was
> >> related to package name changes.
> >>
> >> My style of thinking: x.y.z
> >>
> >> x - no compatibility
> >> y - source compatibility
> >> z - binary compatibility
> >>
> >> is simple and makes sense.
> >>
> >> It's OK to put some burden on the users when upgrading - as long as the
> >> expectations are set correctly.
> >> But I am pretty sure we discussed that before and some people did not
> agree.
> >>
> >> cheers,
> >> Torsten
> >>
> >>
> >>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bodewig@apache.org>
> wrote:
> >>>
> >>>> On 2013-10-08, Emmanuel Bourg wrote:
> >>>>
> >>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> >>>
> >>>>> - loosen API compatibility policy?
> >>>
> >>>> This topic alone deserves its own thread I think.
> >>>
> >>>> Ensuring binary/source compatibility is very important.
> >>>
> >>> +1
> >>>
> >>> I guess I've done too much ruby with "every bundle update runs the risk
> >>> of breaking everything" lately.  I really value the stability commons
> >>> provides.
> >>>
> >>> That being said, I'm sure there are cases where our policy seems
> >>> stricter than it needs to be - even though I haven't seen a really
> >>> difficult case in the one component I contribute to.
> >>>
> >>> Stefan
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Cheers,
Paul

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