On 5 July 2013 17:45, 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.
Only if the dependency is used by another package that is also generally released, e.g. to Maven Central. > 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. The issue is not with Maven Central per se. The same problem can arise with any public release of Alpha code which is made a dependency of something else that is then released. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
