commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [collections] Release 4.0-alpha1 to maven?
Date Fri, 05 Jul 2013 18:58:57 GMT
On 5 July 2013 19:10, Paul Benedict <pbenedict@apache.org> wrote:
> AFAIK, a release is a release. If you're voting on a project, a successful
> vote creates an Apache artifact that needs to be published to the world.

Yes, but ASF software does not have to be released to Maven Central.
The only requirement is to release source, which must be done via the
ASF mirror system.

> Maven just released their 3.1.0-alpha. That release will be forever out
> there, but since it's not production quality, usage will eventually
> drop-off once the GA release is pushed -- but a release is a release. So
> the decision to publish a Collections 4 Alpha should be done under the same
> guidelines.

[Not a good example, as Maven itself is rather different from a
general purpose library; it is not likely to become part of another
product.]

When using Maven Central for Alpha releases, the concern is that it is
more likely to result in a 3rd party product being released that
depends on the Alpha release. That is stupid and wrong, but it could
happen.

Depending on ASF mirror releases is somewhat harder than using Maven
Central, so it may be less likely that a product is released that uses
the Alpha code.
However it could still happen; the Alpha code could be bundled with the product.

In either case, the longer the Alpha code remains the only new
release, the more likely people will ignore the Alpha status and use
it anyway (unless the code is badly broken!)

Given that Maven Central releases cannot be retracted (except in rare
circumstances) I now think it would be worth seeing what happens
without a Maven Central release. We should be able to publish the jars
to Maven later, or spin a new Alpha release which is published to MC.

But I don't think it's wrong in principle to release Alpha code to
Maven, so long as it is made very clear that the API may change.

>
> On Fri, Jul 5, 2013 at 12:41 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>
>>
>>
>> On Jul 5, 2013, at 9:52 AM, Gary Gregory <garydgregory@gmail.com> 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.
>>
>>
>> Good point.  I probably should have said "limited advertisement" or
>> something.  A beta tarball can be pushed to the mirrors and later taken
>> down when the actual release is published.  It will still be available in
>> the archives and likely other places, but it will not be linked on the
>> website or otherwise "advertised" once the stable release is out.  If it is
>> pushed to maven central, it will forever show up among the release versions
>> and builds depending on it will continue to work.  If we can get the
>> feedback we need without this, my HO is that we should avoid it.
>>
>> Phil
>>
>> >
>> > 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.
>> >
>> > Gary
>> >
>> > We should do what we can to limit
>> >> dependency propagation as we get the feedback we are looking for.
>> >> Keeping the artifacts off of maven central will help.  The real
>> >> question is can we get the feedback we need without forever
>> >> advertising these artifacts on maven central.
>> >>
>> >> Phil
>> >>>
>> >>> Gary
>> >>>
>> >>>
>> >>>> Phil
>> >>>>> So long as we don't break the API between non-Alpha releases,
I don't
>> >>>>> see this as a big issue.
>> >>>>>
>> >>>>> However, we do need to ensure that the non-Alpha release is
not left
>> >>>>> too long or people may get impatient and ignore the warnings.
>> >>>>>
>> >>>>>> Phil
>> >>>>>>> Gary
>> >>>>>>>
>> >>>>>>> On Jul 5, 2013, at 4:24, Thomas Neidhart <
>> thomas.neidhart@gmail.com>
>> >>>> wrote:
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>> just to make sure we have agreement on this topic.
>> >>>>>>>> Reading again the thread about release alpha/beta
releases I think
>> >> we
>> >>>> did
>> >>>>>>>> not reach consensus whether to publish alpha releases
to maven
>> >>>> central.
>> >>>>>>>> It would be easier for people to try out things,
but the release
>> >> will
>> >>>> stay
>> >>>>>>>> there forever and some people had objections against
it.
>> >>>>>>>>
>> >>>>>>>> We also know for sure that the API will change,
as we will at
>> least
>> >>>> rename
>> >>>>>>>> one new class introduced for 4.0 (CompliantBag ->
CollectionBag).
>> >>>>>>>>
>> >>>>>>>> So the questions is:
>> >>>>>>>>
>> >>>>>>>> Shall we publish to maven central?
>> >>>>>>>>
>> >>>>>>>> Thomas
>> >>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>> 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
>> >>>>> ---------------------------------------------------------------------
>> >>>>> 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
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message