commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
Date Tue, 30 Apr 2013 18:09:40 GMT
On 4/30/13 10:29 AM, sebb wrote:
> On 30 April 2013 18:25, Phil Steitz <phil.steitz@gmail.com> wrote:
>
>> On 4/30/13 10:19 AM, sebb wrote:
>>> On 30 April 2013 17:52, Phil Steitz <phil.steitz@gmail.com> wrote:
>>>
>>>> On 4/30/13 9:28 AM, sebb wrote:
>>>>> On 30 April 2013 16:59, Honton, Charles <Charles_Honton@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?

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" <sebbaz@gmail.com> wrote:
>>>>>>
>>>>>>> On 30 April 2013 15:51, Gilles <gilles@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-unsubscribe@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message