On 10 February 2018 at 14:20, Gilles <gil...@harfang.homelinux.org> wrote: > On Sat, 10 Feb 2018 13:39:49 +0000, sebb wrote: >> >> 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." > > > 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-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
