On 30 April 2013 18:25, Phil Steitz <phil.ste...@gmail.com> wrote:
> On 4/30/13 10:19 AM, sebb wrote:
> > On 30 April 2013 17:52, Phil Steitz <phil.ste...@gmail.com> wrote:
> >
> >> On 4/30/13 9:28 AM, sebb wrote:
> >>> On 30 April 2013 16:59, Honton, Charles <charles_hon...@intuit.com>
> >> 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?
> >
> >
> >> 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" <seb...@gmail.com> wrote:
> >>>>
> >>>>> On 30 April 2013 15:51, Gilles <gil...@harfang.homelinux.org> 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<
> >> 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
>
>
