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.
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). Since you can't
remove anything from the mirrored maven repos, we chose not to push
the beta jars there. 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.
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
