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. 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.
On Fri, Jul 5, 2013 at 12:41 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > > > On Jul 5, 2013, at 9:52 AM, 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. > > > 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.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 > >
