You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2018/02/10 11:52:24 UTC
[ALL] please remember to tidy up old releases
The 3rd party mirrors all offer their services for free.
Although storage is cheap these days, it is not free, so we should not
burden the mirrors with unnecessary files (*).
So would RMs please remember to remove old releases once a new release
has been announced.
And when preparing for a new release, please check if the existing
download page still carries any obsolete releases. [It is OK to link
to older release on the archive server]
Thanks!
(*) I know Commons packages are generally small, but there are a lot of them.
Also each file generates network traffic (e.g. to check if it is up-to-date).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] please remember to tidy up old releases
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sat, 10 Feb 2018 16:12:55 +0000, sebb wrote:
> On 10 February 2018 at 14:20, Gilles <gi...@harfang.homelinux.org>
> wrote:
>> On Sat, 10 Feb 2018 13:39:49 +0000, sebb wrote:
>>>
>>> On 10 February 2018 at 12:57, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>>
>>>> On Sat, 10 Feb 2018 11:52:24 +0000, sebb wrote:
>>>>>
>>>>>
>>>>> The 3rd party mirrors all offer their services for free.
>>>>>
>>>>> Although storage is cheap these days, it is not free, so we
>>>>> should not
>>>>> burden the mirrors with unnecessary files (*).
>>>>>
>>>>> So would RMs please remember to remove old releases once a new
>>>>> release
>>>>> has been announced.
>>>>>
>>>>> And when preparing for a new release, please check if the
>>>>> existing
>>>>> download page still carries any obsolete releases. [It is OK to
>>>>> link
>>>>> to older release on the archive server]
>>>>
>>>>
>>>>
>>>> What are the criteria for "old", "obsolete", "unnecessary"?
>>>
>>>
>>> http://www.apache.org/dev/release-distribution#archival
>>>
>>> "Each project's distribution directory SHOULD contain the latest
>>> release in each branch that is currently under development.
>>> When development ceases on a version branch, releases of that
>>> branch
>>> SHOULD be removed."
>>
>>
>> Then it's a while that CM should have be removed since
>> development of the MATH_3_X branch ceased years ago.
>
> If this is done, the download page will need to be updated to avoid
> broken links.
>
>>>> In CM for example, we used to add links to the "apidocs" of
>>>> previous releases, even though the consensus was that they
>>>> were not supported.
>>>
>>>
>>> Huh?
>>> This is only about release artifacts on mirrors.
>>> apidocs are not published to the mirrors.
>>
>>
>> My remark was in reference to advertizing APIs of
>> multiple "obsolete" (and to be archived as per your
>> message) versions of CM.
>
> That is nothing to do with this thread,
OK, then I didn't understand what this thread was about.
And I'll stop trying to understand what I'm supposed to
do with it.
Gilles
> which is about tidying up the
> mirrors.
>
>>>> If there is a well-defined requirement
>>>
>>>
>>> See above
>>>
>>>> can the actions be automated? [Check for obsolete files, send a
>>>> warning/reminder
>>>> to the ML, move them to the appropriate location.]
>>>
>>>
>>> Cleanup is relatively infrequent, so whether it is worth automating
>>> is
>>> debatable.
>>>
>>> The ASF reporter app already emails the RM whenever a new release
>>> is
>>> committed to dist/release.
>>>
>>> There should be no releases on the mirrors that are not linked from
>>> the download page, so
>>> it might be possible to extract the release versions from the
>>> download
>>> page, and compare that with the files under dist.
>>
>>
>> Unreachable files should be deleted; fine (no need for automation).
>>
>> But is it OK to provide links to old releases (even if there
>> supposedly obsolete). [Might be useful for a user to identify
>> a regression of change of behaviour.]
>
> Yes of course one can link to archived releases; indeed the Commons
> download pages already do so.
> But again that is drifting off-topic.
>
>> Gilles
>>
>>
>>> However I don't think it's possible to automate fixing the pom
>>> entries
>>> as which versions are current depend on undocumented/unknown
>>> externalities.
>>> For example:
>>> There may be plans to maintain older releases that later get
>>> abandoned.
>>> In the case of DBCP there are multiple versions (1.3, 1.4, 2.0) for
>>> the multiple incompatible versions of JDBC.
>>>
>>> Automation would need to take this all into account.
>>>
>>> However I guess it would be possible to automate the comparison of
>>> the
>>> download pages with the mirror contents.
>>> It would be easier to use the pom, but that might already have been
>>> updated for an upcoming release.
>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>>> Thanks!
>>>>>
>>>>> (*) I know Commons packages are generally small, but there are a
>>>>> lot of
>>>>> them.
>>>>> Also each file generates network traffic (e.g. to check if it is
>>>>> up-to-date).
>>>>>
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] please remember to tidy up old releases
Posted by sebb <se...@gmail.com>.
On 10 February 2018 at 14:20, Gilles <gi...@harfang.homelinux.org> wrote:
> On Sat, 10 Feb 2018 13:39:49 +0000, sebb wrote:
>>
>> On 10 February 2018 at 12:57, Gilles <gi...@harfang.homelinux.org> wrote:
>>>
>>> On Sat, 10 Feb 2018 11:52:24 +0000, sebb wrote:
>>>>
>>>>
>>>> The 3rd party mirrors all offer their services for free.
>>>>
>>>> Although storage is cheap these days, it is not free, so we should not
>>>> burden the mirrors with unnecessary files (*).
>>>>
>>>> So would RMs please remember to remove old releases once a new release
>>>> has been announced.
>>>>
>>>> And when preparing for a new release, please check if the existing
>>>> download page still carries any obsolete releases. [It is OK to link
>>>> to older release on the archive server]
>>>
>>>
>>>
>>> What are the criteria for "old", "obsolete", "unnecessary"?
>>
>>
>> http://www.apache.org/dev/release-distribution#archival
>>
>> "Each project's distribution directory SHOULD contain the latest
>> release in each branch that is currently under development.
>> When development ceases on a version branch, releases of that branch
>> SHOULD be removed."
>
>
> Then it's a while that CM should have be removed since
> development of the MATH_3_X branch ceased years ago.
If this is done, the download page will need to be updated to avoid
broken links.
>>> In CM for example, we used to add links to the "apidocs" of
>>> previous releases, even though the consensus was that they
>>> were not supported.
>>
>>
>> Huh?
>> This is only about release artifacts on mirrors.
>> apidocs are not published to the mirrors.
>
>
> My remark was in reference to advertizing APIs of
> multiple "obsolete" (and to be archived as per your
> message) versions of CM.
That is nothing to do with this thread, which is about tidying up the mirrors.
>>> If there is a well-defined requirement
>>
>>
>> See above
>>
>>> can the actions be automated? [Check for obsolete files, send a
>>> warning/reminder
>>> to the ML, move them to the appropriate location.]
>>
>>
>> Cleanup is relatively infrequent, so whether it is worth automating is
>> debatable.
>>
>> The ASF reporter app already emails the RM whenever a new release is
>> committed to dist/release.
>>
>> There should be no releases on the mirrors that are not linked from
>> the download page, so
>> it might be possible to extract the release versions from the download
>> page, and compare that with the files under dist.
>
>
> Unreachable files should be deleted; fine (no need for automation).
>
> But is it OK to provide links to old releases (even if there
> supposedly obsolete). [Might be useful for a user to identify
> a regression of change of behaviour.]
Yes of course one can link to archived releases; indeed the Commons
download pages already do so.
But again that is drifting off-topic.
> Gilles
>
>
>> However I don't think it's possible to automate fixing the pom entries
>> as which versions are current depend on undocumented/unknown
>> externalities.
>> For example:
>> There may be plans to maintain older releases that later get abandoned.
>> In the case of DBCP there are multiple versions (1.3, 1.4, 2.0) for
>> the multiple incompatible versions of JDBC.
>>
>> Automation would need to take this all into account.
>>
>> However I guess it would be possible to automate the comparison of the
>> download pages with the mirror contents.
>> It would be easier to use the pom, but that might already have been
>> updated for an upcoming release.
>>
>>> Regards,
>>> Gilles
>>>
>>>> Thanks!
>>>>
>>>> (*) I know Commons packages are generally small, but there are a lot of
>>>> them.
>>>> Also each file generates network traffic (e.g. to check if it is
>>>> up-to-date).
>>>>
>>>
>
>
> ---------------------------------------------------------------------
> 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: [ALL] please remember to tidy up old releases
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sat, 10 Feb 2018 13:39:49 +0000, sebb wrote:
> On 10 February 2018 at 12:57, Gilles <gi...@harfang.homelinux.org>
> wrote:
>> On Sat, 10 Feb 2018 11:52:24 +0000, sebb wrote:
>>>
>>> The 3rd party mirrors all offer their services for free.
>>>
>>> Although storage is cheap these days, it is not free, so we should
>>> not
>>> burden the mirrors with unnecessary files (*).
>>>
>>> So would RMs please remember to remove old releases once a new
>>> release
>>> has been announced.
>>>
>>> And when preparing for a new release, please check if the existing
>>> download page still carries any obsolete releases. [It is OK to
>>> link
>>> to older release on the archive server]
>>
>>
>> What are the criteria for "old", "obsolete", "unnecessary"?
>
> http://www.apache.org/dev/release-distribution#archival
>
> "Each project's distribution directory SHOULD contain the latest
> release in each branch that is currently under development.
> When development ceases on a version branch, releases of that branch
> SHOULD be removed."
Then it's a while that CM should have be removed since
development of the MATH_3_X branch ceased years ago.
>> In CM for example, we used to add links to the "apidocs" of
>> previous releases, even though the consensus was that they
>> were not supported.
>
> Huh?
> This is only about release artifacts on mirrors.
> apidocs are not published to the mirrors.
My remark was in reference to advertizing APIs of
multiple "obsolete" (and to be archived as per your
message) versions of CM.
>> If there is a well-defined requirement
>
> See above
>
>> can the actions be automated? [Check for obsolete files, send a
>> warning/reminder
>> to the ML, move them to the appropriate location.]
>
> Cleanup is relatively infrequent, so whether it is worth automating
> is
> debatable.
>
> The ASF reporter app already emails the RM whenever a new release is
> committed to dist/release.
>
> There should be no releases on the mirrors that are not linked from
> the download page, so
> it might be possible to extract the release versions from the
> download
> page, and compare that with the files under dist.
Unreachable files should be deleted; fine (no need for automation).
But is it OK to provide links to old releases (even if there
supposedly obsolete). [Might be useful for a user to identify
a regression of change of behaviour.]
Gilles
> However I don't think it's possible to automate fixing the pom
> entries
> as which versions are current depend on undocumented/unknown
> externalities.
> For example:
> There may be plans to maintain older releases that later get
> abandoned.
> In the case of DBCP there are multiple versions (1.3, 1.4, 2.0) for
> the multiple incompatible versions of JDBC.
>
> Automation would need to take this all into account.
>
> However I guess it would be possible to automate the comparison of
> the
> download pages with the mirror contents.
> It would be easier to use the pom, but that might already have been
> updated for an upcoming release.
>
>> Regards,
>> Gilles
>>
>>> Thanks!
>>>
>>> (*) I know Commons packages are generally small, but there are a
>>> lot of
>>> them.
>>> Also each file generates network traffic (e.g. to check if it is
>>> up-to-date).
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] please remember to tidy up old releases
Posted by sebb <se...@gmail.com>.
On 10 February 2018 at 12:57, Gilles <gi...@harfang.homelinux.org> wrote:
> On Sat, 10 Feb 2018 11:52:24 +0000, sebb wrote:
>>
>> The 3rd party mirrors all offer their services for free.
>>
>> Although storage is cheap these days, it is not free, so we should not
>> burden the mirrors with unnecessary files (*).
>>
>> So would RMs please remember to remove old releases once a new release
>> has been announced.
>>
>> And when preparing for a new release, please check if the existing
>> download page still carries any obsolete releases. [It is OK to link
>> to older release on the archive server]
>
>
> What are the criteria for "old", "obsolete", "unnecessary"?
http://www.apache.org/dev/release-distribution#archival
"Each project's distribution directory SHOULD contain the latest
release in each branch that is currently under development.
When development ceases on a version branch, releases of that branch
SHOULD be removed."
> In CM for example, we used to add links to the "apidocs" of
> previous releases, even though the consensus was that they
> were not supported.
Huh?
This is only about release artifacts on mirrors.
apidocs are not published to the mirrors.
> If there is a well-defined requirement
See above
> can the actions be automated? [Check for obsolete files, send a warning/reminder
> to the ML, move them to the appropriate location.]
Cleanup is relatively infrequent, so whether it is worth automating is
debatable.
The ASF reporter app already emails the RM whenever a new release is
committed to dist/release.
There should be no releases on the mirrors that are not linked from
the download page, so
it might be possible to extract the release versions from the download
page, and compare that with the files under dist.
However I don't think it's possible to automate fixing the pom entries
as which versions are current depend on undocumented/unknown
externalities.
For example:
There may be plans to maintain older releases that later get abandoned.
In the case of DBCP there are multiple versions (1.3, 1.4, 2.0) for
the multiple incompatible versions of JDBC.
Automation would need to take this all into account.
However I guess it would be possible to automate the comparison of the
download pages with the mirror contents.
It would be easier to use the pom, but that might already have been
updated for an upcoming release.
> Regards,
> Gilles
>
>> Thanks!
>>
>> (*) I know Commons packages are generally small, but there are a lot of
>> them.
>> Also each file generates network traffic (e.g. to check if it is
>> up-to-date).
>>
>
>
> ---------------------------------------------------------------------
> 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: [ALL] please remember to tidy up old releases
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sat, 10 Feb 2018 11:52:24 +0000, sebb wrote:
> The 3rd party mirrors all offer their services for free.
>
> Although storage is cheap these days, it is not free, so we should
> not
> burden the mirrors with unnecessary files (*).
>
> So would RMs please remember to remove old releases once a new
> release
> has been announced.
>
> And when preparing for a new release, please check if the existing
> download page still carries any obsolete releases. [It is OK to link
> to older release on the archive server]
What are the criteria for "old", "obsolete", "unnecessary"?
In CM for example, we used to add links to the "apidocs" of
previous releases, even though the consensus was that they
were not supported.
If there is a well-defined requirement, can the actions be
automated? [Check for obsolete files, send a warning/reminder
to the ML, move them to the appropriate location.]
Regards,
Gilles
> Thanks!
>
> (*) I know Commons packages are generally small, but there are a lot
> of them.
> Also each file generates network traffic (e.g. to check if it is
> up-to-date).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org