Gary Gregory 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. > > 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
