On 10 February 2018 at 12:57, Gilles <gil...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
