Adding -bin to artifact names is a separate issue, please start a new thread.
On 18 April 2016 at 10:43, Stian Soiland-Reyes <st...@apache.org> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
