On 4/30/13 10:29 AM, sebb wrote: > On 30 April 2013 18:25, Phil Steitz <[email protected]> wrote: > >> On 4/30/13 10:19 AM, sebb wrote: >>> On 30 April 2013 17:52, Phil Steitz <[email protected]> wrote: >>> >>>> On 4/30/13 9:28 AM, sebb wrote: >>>>> On 30 April 2013 16:59, Honton, Charles <[email protected]> >>>> wrote: >>>>>> Is there any policy concern with publishing the binaries of alpha >>>>>> releases, after vote, to a Apache snapshot repository which is not >>>>>> replicated to Maven Central? >>>>>> >>>>>> >>>>> Not sure that question makes sense as posed. >>>>> >>>>> If a build is voted on, it is a release, and is not a snapshot. >>>>> AFAIK snapshots are never voted on so cannot become releases. >>>>> >>>>> Snapshots can be uploaded to a snaphot repo without needing a vote. >>>>> >>>>> Snapshots can (*) only be uploaded to snapshot repos; they cannot be >>>>> uploaded to release repos. >>>>> AFAIK the reverse is also true, releases are never uploaded to snapshot >>>>> repos. >>>> IIRC, what we did with the [lang] 3.0 betas was not push the beta >>>> releases to maven central, but we *did* update the snapshot repos. >>>> >>> I'm not sure it's possible to upload a non-SNAPSHOT bundle to the >> snapshots >>> repo via Nexus, but I could be wrong. >> It was labelled 3.0-SNAPSHOT, IIRC. >> >> > But surely that's not an Alpha or a Beta release?
The actual release is what is on the ASF mirrors. Pointing people at the SNAPSHOT for maven-assisted testing was a workaround. Seems a reasonable workaround to me. The problem with the public maven repos is you can never delete anything from them and we don't want the betas to be long-lived in the wild. Phil > > >>> >>>> This seems a sensible policy to me. Alpha / beta releases are >>>> pushed to the mirrors as tars / zips and then *removed* once the >>>> "stable" release is cut (you can see there is no trace of the lang 3 >>>> betas in the archives or linked on the site). >>> I thought the ASF archive site was supposed to contain everything that >> had >>> ever been released? >>> >>> And indeed the beta tarballs are still there. >>> However as you say, they are not referenced elsewhere, so that will do no >>> harm. >>> >>> Since you can't >>>> remove anything from the mirrored maven repos, we chose not to push >>>> the beta jars there. >>> That is always an option, though it may make it somewhat harder to >>> reference the dependency in Maven. >>> >>>> Seems to have worked OK for the [lang] 3 >>>> betas. I would say do the same thing for [collections] 4 and others >>>> that are making major API changes and want to get user feedback >>>> before pouring cement. >>>> >>> Provided that the API does not change incompatibly, then there is no >> issue >>> with publishing Alpha and Beta releases to Maven Central. >>> Likewise, provided users take heed of any warnings about possible API >>> changes in Alpha releases then there is no problem. >>> They will either not release jars that depend on the Alpha code, or if >> they >>> do, they must propagate the warning and update their jar as soon as a new >>> release comes out. >>> >>> Seems to me what we are guarding against here is users who ignore >> warnings >>> that the API might change. >>> >>> If we can do that easily, then fine, let's try and do it. >>> But there's only so far that we should go in order to guard against users >>> who ignore such warnings. >>> >>> Phil >>>>> Note that the entries in a snapshot repo can be deleted/replaced at any >>>>> time. >>>>> >>>>> (*) Before Nexus, accidents happened and some snapshots were >> incorrectly >>>>> uploaded. This can cause "version hell" (cf. "jar hell"). >>>>> >>>>> Chas >>>>>> On 4/30/13 8:28 AM, "sebb" <[email protected]> wrote: >>>>>> >>>>>>> On 30 April 2013 15:51, Gilles <[email protected]> wrote: >>>>>>> >>>>>>>> On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: >>>>>>>> >>>>>>>>> On 4/29/13 11:49 PM, Thomas Vandahl wrote: >>>>>>>>> >>>>>>>>>> On 30.04.2013 00:01, Gilles wrote: >>>>>>>>>> >>>>>>>>>>> If someone doesn't develop a Commons component, he is not in the >>>>>>>>>>> "developer" >>>>>>>>>>> category for that component. >>>>>>>>>>> If his app _uses_ a Commons component, he is a "user" of that >>>>>>>>>>> component. >>>>>>>>>>> This kind of users should indeed be encouraged to test snapshots, >>>>>>>>>>> and >>>>>>>>>>> report >>>>>>>>>>> problems _before_ an official release is made. >>>>>>>>>>> >>>>>>>>>> I completely agree with you. Looking at the Commons components, >>>>>>>>>> all "users" are also "developers" one way or another, as the >>>>>>>>>> components are merley libraries, not applications. >>>>>>>>>> >>>>>>>>>> From what I understand of the Maven idea, snapshots are *the* way >>>>>>>>>> binaries can be distributed for testing - including separate >>>>>>>>>> storage in a separate repository. The whole repository >>>>>>>>>> infrastructure was made for this. The snapshot status carries the >>>>>>>>>> clear message that this binary is not for production use and can >>>>>>>>>> change its API anytime. So why not use this? >>>>>>>>>> >>>>>>>>> The problem with "publicising" snapshots is that it makes it look >>>>>>>>> like they are actual releases. This has been discussed a lot over >>>>>>>>> the years, and we have settled on the policy [1] that anything that >>>>>>>>> we encourage anyone beyond the developers actively following the >> dev >>>>>>>>> list ("developers" per the definition above), *must* be treated as >> a >>>>>>>>> release. >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://www.apache.org/dev/**release.html#what< >>>>>> http://www.apache.org/dev/ >>>>>>>>> release.html#what> >>>>>>>>> >>>>>>>> Thanks for this clarification. >>>>>>>> >>>>>>>> Unfortunately, the description of "release" does not provide a >>>> solution >>>>>>>> to the problem posed. >>>>>>>> Essentially, it only forbids to ask for user feedback on >> "unreleased" >>>>>>>> code. >>>>>>>> >>>>>>>> >>>>>>> Not entirely; if a user is participating in development via bug >> reports >>>>>>> and >>>>>>> patches, they can be directed to snapshots for testing. >>>>>>> >>>>>>> >>>>>>>> The only way out is to release: >>>>>>>> "If this policy seems inconvenient, then release more often." >>>>>>>> >>>>>>>> But release what? "alpha", "beta"? Those are not defined there. >>>>>>>> If such releases are done, then what policy wrt to user support? >>>>>>>> E.g. do we _have_ to (quickly) create bug fix releases for such >>>> releases >>>>>>>> (known to be more fragile)? >>>>>>>> >>>>>>>> This looks much more complicated than just asking interested parties >>>> to >>>>>>>> "manually" download a nightly build (with all the caveats and >>>> warnings), >>>>>>>> temporarily add it to their classpath and look for unexpected >>>> problems. >>>>>>> It's not either/or here. >>>>>>> >>>>>>> Snapshots are not prohibited. >>>>>>> >>>>>>> It's possible for interested parties to use snapshots. >>>>>>> >>>>>>> >>>>>>>> Gilles >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> ------------------------------**------------------------------**--------- >>>>>>>> To unsubscribe, e-mail: >>>>>>>> dev-unsubscribe@commons.**apache.org< >>>> [email protected]> >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
