You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Honton, Charles" <Ch...@intuit.com> on 2013/04/30 17:59:02 UTC
[PMC] Alpha Binaries Release Policy (was Re: [collections] beta
release - howto)
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?
Chas
On 4/30/13 8:28 AM, "sebb" <se...@gmail.com> wrote:
>On 30 April 2013 15:51, Gilles <gi...@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<de...@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
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta
release - howto)
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 30/04/2013 17:59, Honton, Charles a écrit :
> 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?
I don't know, but nightly builds are already pushed to the snapshot
repository:
https://repository.apache.org/content/groups/snapshots/org/apache/commons/
Emmanuel Bourg
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
Posted by Jörg Schaible <jo...@gmx.de>.
Phil Steitz wrote:
> On 4/30/13 10:29 AM, sebb wrote:
>> On 30 April 2013 18:25, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> On 4/30/13 10:19 AM, sebb wrote:
>>>> On 30 April 2013 17:52, Phil Steitz <ph...@gmail.com> wrote:
>>>>
>>>>> On 4/30/13 9:28 AM, sebb wrote:
>>>>>> On 30 April 2013 16:59, Honton, Charles <Ch...@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.
+1
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta
release - howto)
Posted by Phil Steitz <ph...@gmail.com>.
On 4/30/13 10:29 AM, sebb wrote:
> On 30 April 2013 18:25, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 4/30/13 10:19 AM, sebb wrote:
>>> On 30 April 2013 17:52, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>> On 4/30/13 9:28 AM, sebb wrote:
>>>>> On 30 April 2013 16:59, Honton, Charles <Ch...@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" <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 30 April 2013 15:51, Gilles <gi...@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
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta
release - howto)
Posted by sebb <se...@gmail.com>.
On 30 April 2013 18:25, Phil Steitz <ph...@gmail.com> wrote:
> On 4/30/13 10:19 AM, sebb wrote:
> > On 30 April 2013 17:52, Phil Steitz <ph...@gmail.com> wrote:
> >
> >> On 4/30/13 9:28 AM, sebb wrote:
> >>> On 30 April 2013 16:59, Honton, Charles <Ch...@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" <se...@gmail.com> wrote:
> >>>>
> >>>>> On 30 April 2013 15:51, Gilles <gi...@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
>
>
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta
release - howto)
Posted by Phil Steitz <ph...@gmail.com>.
On 4/30/13 10:19 AM, sebb wrote:
> On 30 April 2013 17:52, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 4/30/13 9:28 AM, sebb wrote:
>>> On 30 April 2013 16:59, Honton, Charles <Ch...@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" <se...@gmail.com> wrote:
>>>>
>>>>> On 30 April 2013 15:51, Gilles <gi...@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
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta
release - howto)
Posted by sebb <se...@gmail.com>.
On 30 April 2013 17:52, Phil Steitz <ph...@gmail.com> wrote:
> On 4/30/13 9:28 AM, sebb wrote:
> > On 30 April 2013 16:59, Honton, Charles <Ch...@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.
> 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" <se...@gmail.com> wrote:
> >>
> >>> On 30 April 2013 15:51, Gilles <gi...@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
>
>
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta
release - howto)
Posted by Phil Steitz <ph...@gmail.com>.
On 4/30/13 9:28 AM, sebb wrote:
> On 30 April 2013 16:59, Honton, Charles <Ch...@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" <se...@gmail.com> wrote:
>>
>>> On 30 April 2013 15:51, Gilles <gi...@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<de...@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
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta
release - howto)
Posted by sebb <se...@gmail.com>.
On 30 April 2013 16:59, Honton, Charles <Ch...@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" <se...@gmail.com> wrote:
>
> >On 30 April 2013 15:51, Gilles <gi...@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<de...@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
>
>