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