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