commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL] please remember to tidy up old releases
Date Sat, 10 Feb 2018 19:07:04 GMT
On Sat, 10 Feb 2018 16:12:55 +0000, sebb wrote:
> On 10 February 2018 at 14:20, Gilles <gilles@harfang.homelinux.org> 
> wrote:
>> On Sat, 10 Feb 2018 13:39:49 +0000, sebb wrote:
>>>
>>> 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."
>>
>>
>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message