commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [collections] Release 4.0-alpha1 to maven?
Date Fri, 05 Jul 2013 16:32:08 GMT
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.

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


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

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