Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <ac5fd8e53fccb059fef9d0b58e8fbb31@scarlet.be>
References: 
 <CAOGo0VaTDvAXGj=0RmJW2g2-6PHezEke0VC6rK-YF+Y1fNKuaw@mail.gmail.com>
	<CAMBJEmU0v8E4qhhC+7L4RML-9C_cizNmYMMKTCup+TcYkQYJyA@mail.gmail.com>
	<CAMBJEmXRHf49nR8FewCWtrDfdpLd9ejoVEsJwbFyD=S3oJYc6A@mail.gmail.com>
	<CAMBJEmU5fFYyuqGGVzu_W7svp58cK2YJ866-aTe5D=SHH=j=uw@mail.gmail.com>
	<ac5fd8e53fccb059fef9d0b58e8fbb31@scarlet.be>
Date: Mon, 18 Apr 2016 10:22:53 +0100
Message-ID: 
 <CAMBJEmUG9S-Aw2y+s6DXLi7N+_0LtOjzOxLCme6FsG6+U-hKpg@mail.gmail.com>
Subject: Re: [ALL] Dist layout change to per version directories
From: Stian Soiland-Reyes <stain@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=089e0141a190c20f460530bee7d6

--089e0141a190c20f460530bee7d6
Content-Type: text/plain; charset=UTF-8

Changing download links for all existing releases (without a new release)
sounds worse than having slightly inconsistent paths for a while.

Moving the existing releases would also cause duplicates on
archive.apache.org (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" <gilles@harfang.homelinux.org> 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
>>
>> https://archive.apache.org/commons/foo/source/foo-${version}-src.tar.gz
>>
>> (They have to use archive as older versions disappear from official
>> mirrors)
>> On 16 Apr 2016 00:02, "sebb" <sebbaz@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

--089e0141a190c20f460530bee7d6--