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 <gil...@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" <gil...@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" <seb...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
