commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
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
https://issues.apache.org/jira/browse/INFRA-11702
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:


stain@biggie:~/Downloads/912/mirrors.ukfast.co.uk/sites/ftp.apache.org$
find . -type f | grep -v txt  | grep -v -- -src.tar.gz | grep -v --
-src.zip | grep -v -- -bin.zip | grep -v -- -bin.tar.gz

./commons/proxy/binaries/commons-proxy-1.0.tar.gz
./commons/proxy/binaries/commons-proxy-1.0.zip
./commons/primitives/binaries/commons-primitives-1.0.tar.gz
./commons/primitives/binaries/commons-primitives-1.0.zip
./commons/jexl/binaries/commons-jexl-1.1.tar.gz
./commons/jexl/binaries/commons-jexl-1.1.zip
./commons/attributes/binaries/commons-attributes-2.2.tar.gz
./commons/attributes/binaries/commons-attributes-2.2.zip
./commons/bsf/binaries/bsf-bin-2.4.0.tar.gz
./commons/bsf/binaries/bsf-bin-2.4.0.zip
./commons/bsf/source/bsf-src-2.4.0.tar.gz
./commons/bsf/source/bsf-src-2.4.0.zip
./commons/el/binaries/commons-el-1.0.zip
./commons/el/binaries/commons-el-1.0.tar.gz
./commons/vfs/binaries/commons-vfs-2.0.tar.gz
./commons/vfs/binaries/commons-vfs-2.0.zip
./commons/betwixt/binaries/commons-betwixt-0.8.zip
./commons/betwixt/binaries/commons-betwixt-0.8.tar.gz
./commons/bcel/binaries/bcel-5.2.tar.gz
./commons/bcel/binaries/bcel-5.2.zip
./commons/daemon/binaries/commons-daemon-1.0.15.jar
./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows.zip
./commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows-signed.zip
./commons/jelly/binaries/commons-jelly-1.0.zip
./commons/jelly/binaries/commons-jelly-1.0.tar.gz
./commons/launcher/binaries/commons-launcher-1.1.tar.gz
./commons/launcher/binaries/commons-launcher-1.1-example.tar.gz
./commons/launcher/binaries/commons-launcher-1.1.zip
./commons/launcher/binaries/commons-launcher-1.1-example.zip
./commons/transaction/binaries/commons-transaction-1.2.zip
./commons/transaction/binaries/commons-transaction-1.2.tar.gz
./commons/modeler/binaries/commons-modeler-2.0.1.tar.gz
./commons/modeler/binaries/commons-modeler-2.0.1.zip
./commons/sanselan/binaries/apache-sanselan-incubating-0.97-bin.tar.bz2
./commons/sanselan/source/apache-sanselan-incubating-0.97-src.tar.bz2
./commons/math/binaries/commons-math-2.2.tar.gz
./commons/math/binaries/commons-math-2.2.zip
./commons/net/binaries/commons-net-1.4.1.tar.gz
./commons/net/binaries/commons-net-1.4.1.zip
./commons/jcs/binaries/jcs-1.3.tar.gz
./commons/jcs/binaries/jcs-1.3.zip

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
layout.



On 18 April 2016 at 10:28, Gilles <gilles@harfang.homelinux.org> 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
>> 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
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message