commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] please remember to tidy up old releases
Date Sat, 10 Feb 2018 13:39:49 GMT
On 10 February 2018 at 12:57, Gilles <gilles@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


Mime
View raw message