commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [ALL] please remember to tidy up old releases
Date Sat, 10 Feb 2018 14:20:44 GMT
On Sat, 10 Feb 2018 13:39:49 +0000, sebb wrote:
> On 10 February 2018 at 12:57, Gilles <> 
> 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"?
> "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.]


> 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:
For additional commands, e-mail:

View raw message