On 5 July 2013 17:52, Gary Gregory <garydgreg...@gmail.com> wrote: > On Fri, Jul 5, 2013 at 12:45 PM, Phil Steitz <phil.ste...@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.ste...@gmail.com> >> wrote: >> > >> >> On 7/5/13 7:59 AM, sebb wrote: >> >>> On 5 July 2013 15:47, Phil Steitz <phil.ste...@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.
Agreed. > 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. That would obviously avoid jar hell (N.B. the Maven coords also need to change). However: the names will need to change *even if* the API does *not* break for the GA release. I think that's worse than changing the names *only if* it turns out that the API needs to be broken. > 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.neidh...@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-unsubscr...@commons.apache.org >> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>>>> >> >>>>> . >> >>>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>> >> >>> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> > >> >> >> --------------------------------------------------------------------- >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
