commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <>
Subject Re: [ALL] Dist layout change to per version directories
Date Mon, 18 Apr 2016 09:43:03 GMT
Ah - as long as the INFRA and Mirror guys are OK with the potentially
extra 500 MB then that sounds good!

I've raised
to enquire how we should best do it.

BTW - the -bin and -src suffixes are quite consistent across the
boards. These are the only files that don't match that pattern:

find . -type f | grep -v txt  | grep -v -- -src.tar.gz | grep -v -- | grep -v -- | grep -v -- -bin.tar.gz


Most of those are binaries that simply lack "-bin" (oh no!) - so they
could just be changed to the new pattern manually within the new

On 18 April 2016 at 10:28, Gilles <> wrote:
> On Mon, 18 Apr 2016 10:22:53 +0100, Stian Soiland-Reyes wrote:
>> Changing download links for all existing releases (without a new release)
>> sounds worse than having slightly inconsistent paths for a while.
> I did not suggest to _delete_ anything.
> Just that current archives should be accessible through both old and
> new scripts. The latter not having to deal with the old layout.
> Gilles
>> Moving the existing releases would also cause duplicates on
>> (unless we ask INFRA to reorganise this as well, which
>> would break even permalink downloads)
>> However it is also likely that some of the many stable commons components
>> won't get a new release in a while (many releases are from 2013 or 2014),
>> so such inconsistency could take long to get rid off.
>> Would the mirror folks kill us if we do an svn symlinks from the existing
>> releases to the new layout and let the existing stay until they have been
>> replaced by newer versions?  (This would add another 550 MB for mirrors
>> that don't understand symlinks)
>> On 18 Apr 2016 09:55, "Gilles" <> wrote:
>>> On Mon, 18 Apr 2016 09:12:16 +0100, Stian Soiland-Reyes wrote:
>>>> +1 for the change for future releases. Being able to do svn mv (or rm)
>>>> on
>>>> a
>>>> single folder simplifies releasing and reduces chance of errors.
>>> I think that your remark below calls for making the changes for all
>>> components right now.
>>> Otherwise scripts will require to behave differently for different
>>> components, and force maintainers modify them each time a component
>>> adopts the new scheme.
>>> The new directories should be created also for existing releases, so
>>> that maintainers will have to change their scripts only once.
>>> Gilles
>>> Is the -src and -bin endings already used across all of Commons? That
>>> would
>>>> be a bit more important without source/ and binaries/
>>>> (Do some have download artifacts beyond bin and src?)
>>>> I think it is important to mention this URL pattern change in release
>>>> notes
>>>> for downstream distributors, e.g. Debian recipies that download
>>>> (They have to use archive as older versions disappear from official
>>>> mirrors)
>>>> On 16 Apr 2016 00:02, "sebb" <> wrote:
>>>> The dist layout currently splits archives into source/ and binaries/.
>>>>> Where there are multiple active versions, these are all in the same
>>>>> directory.
>>>>> IMO this layout is not ideal any more.
>>>>> It is harder to tidy up old releases (files have to be individually
>>>>> deleted)
>>>>> It is harder to move files from dist/dev to dist/release
>>>>> Are there any disadvantages to allowing the layout to change?
>>>>> Unless there are objections, I propose to update the commons build
>>>>> plugin to support download pages using version ids, e.g. instead of
>>>>> the present layout:
>>>>> lang/source/commons-lang-2.6-src.*
>>>>> lang/source/commons-lang3-3.4-src.*
>>>>> lang/binaries/commons-lang-2.6-bin.*
>>>>> lang/binaries/commons-lang3-3.4-bin.*
>>>>> It would look like:
>>>>> lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
>>>>> lang/commons-lang3-3.4/commons-lang3-3.4-[bin|src].*
>>>>> Note: I don't think we should move the existing releases
>>>>> The intention is to allow new releases to optionally migrate to the new
>>>>> layout.
>>>>> This would be done on the basis of a new property, e.g.
>>>>> commons.release.layout=version
>>>>> If the property is defined, then the new layout is used; if not, then
>>>>> the current source/binaries layout is used.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message