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