commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [collections] Release 4.0-alpha1 to maven?
Date Fri, 05 Jul 2013 17:18:22 GMT
Gary Gregory wrote:

> On Fri, Jul 5, 2013 at 12:45 PM, Phil Steitz <phil.steitz@gmail.com>
> wrote:
> 
>> On 7/5/13 9:32 AM, Gary Gregory wrote:
>> > On Fri, Jul 5, 2013 at 11:33 AM, Phil Steitz <phil.steitz@gmail.com>
>> wrote:
>> >
>> >> On 7/5/13 7:59 AM, sebb wrote:
>> >>> On 5 July 2013 15:47, Phil Steitz <phil.steitz@gmail.com> wrote:
>> >>>> On 7/5/13 4:35 AM, Gary Gregory wrote:
>> >>>>> Over at log4j we release betas to maven central. I think we
should
>> >>>>> do so here too for alphas. It's just too much of a pain to use
a
>> >>>>> jar in
>> a
>> >>>>> build otherwise.
>> >>>> Do you subsequently introduce incompatible API changes with no
>> >>>> package name change in the "stable" releases?  That's what I would
>> >>>> worry about here.  Collections is so widely used / depended on that
>> >>>> having API-incompatible versions with the same package name
>> >>>> eternally in the wild would seem a bad idea to me.
>> >>> Surely API-instability is part of the point of an Alpha release?
>> >>>
>> >>> Users should be aware that if *they* release anything that depends on
>> >>> an Alpha release it may cause breakage in the futiure.
>> >> It would be great if we and all downstream users of whatever stuff
>> >> ends up shipping with a dependency on a to-be-broken API could
>> >> depend on that.  History suggests that you really can't count on
>> >> that.   The problem is that it is not just or even primarily the
>> >> immediate "users" who get hurt by this.  If it were just the case of
>> >> project A direct user of the alpha breaking, I would agree.  For
>> >> something like [collections], though, the problem is project A ships
>> >> with alpha dependency, gets consumed by B, itself consumed by C, ...
>> >> and some poor soul trying to use the actual release in Z get borked
>> >> because somewhere along the line the now-abandoned A with
>> >> incompatible not package-renamed classes got consumed.
>> >>
>> > This problem happens already today with normal releases of software,
>> > just with behavior changes, not even API breakages.
>> >
>> > At least with an alpha or beta label we are explicitly warning users.
>> >
>> > If *you* choose to release with a dependency on an alpha or beta
>> component,
>> > then *you* are creating a potential problem.
>> >
>> > Similarly, if *you* choose to consume a project with direct
>> > dependencies
>> on
>> > an alpha or beta, that should raise a red flag, and are also possibly
>> > creating a problem.
>> >
>> > The jar hell of transitive dependencies is well know and this does not
>> make
>> > it any better or worse.
>>
>> It *does* make it worse whenever you release incompatible versions
>> of the same class.  This is why we agreed to change package names
>> when we do that.  We have agreed to make an exception for limited
>> distribution alphas / betas.
> 
> 
> There is no such thing as "limited distribution" IMO, if it's accessible
> on the internet, then it's open for business.
> 
> How about putting "alpha" in the package name? That would work for major
> releases like collection 4 which will come in a new package anyway.
> 
> So, call the root package o.a.c.collections4.alpha1. So if you want to use
> it, you have to hard wire to it and jump through a special hoop. Same when
> alpha2 and beta1 come out. Then when it's the real release, it's just
> plain o.a.c.collections4.

Hehehe, using the shade-plugin as post-package step ;-)

- Jörg


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


Mime
View raw message