On Sat, 10 Feb 2018 16:12:55 +0000, sebb wrote:
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,
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
