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