On 3 May 2016 at 11:13, Stian Soiland-Reyes <st...@apache.org> wrote:
> Trying to summarize here.. :)
>
> On 25 April 2016 at 10:49, sebb <seb...@gmail.com> wrote:
>
>>>> Does it really matter if the URL changes more than just a version string?
>>> Yes,
>> I don't understand why that should be.
>> Can you explain in more detail?
>
> Mainly in download recipes with a URL pattern patterns using
> ${version} or similar.
>
> For instance:
>
> https://anonscm.debian.org/cgit/pkg-java/commons-io.git/tree/debian/watch
> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/java-commons-io
>
>
> Obviously these patterns will for the next versions need to change
> anyway with the new layout (they already have to deal with the fact
> that only the newest version is in the mirrors, that's why Debian
> clone into their own git repositories based on that watch file)
>
> Personally when using Apache software from a Docker build file I have
> to use http://archive.apache.org/ fallback URLs to make sure my recipe
> keeps working - see for instance
> https://github.com/stain/jena-docker/blob/master/jena/Dockerfile#L34
>
> But the old releases won't be affected on archive.apache.org (e.g.
> they will stay in */source */binarines).
>
>
>
>> Unless we continue providing links for every future release, the
>> downstream provider has to change the download URL.
>> Once they have done that, why should there be a need to refer to
>> previous releases at all?
>> And if there is a need to do so, does it really matter if the URL is
>> different?
>
> I agree it doesn't matter if it's a new versions - as they will come
> with release emails and so on. However I don't think consumers expect
> existing Download links to change over night without a corresponding
> new release email for that component.
>
> We should of course do a general release email about the download link
> changes - but then we still have a job to ensure we have updated all
> our own download pages correctly :)
>
> https://archive.apache.org/dist/commons/ would still keep the older
> versions under binaries/ and sources/ - I don't suggest to make
> symlinks for every old release in there to the new pattern.
>
>
> The question is what to do with the existing releases in the mirrors.
>
> I think from INFRA-11702 we have OK from INFRA to use symlinks for
> this if we want - e.g. from the new folder structure to the old one -
> so my suggestion is that we make the change smoother for downstream
> like that.
>
> e.g let's consider
>
> https://dist.apache.org/repos/dist/release/commons/math/
>
> Current structure (for simplicity only showing *.tar.gz):
>
> ./source/commons-math-2.2-src.tar.gz
> ./source/commons-math3-3.6-src.tar.gz
> ./source/commons-math3-3.6.1-src.tar.gz
> ./source/commons-math3-3.5-src.tar.gz
> ./binaries/commons-math3-3.5-bin.tar.gz
> ./binaries/commons-math-2.2.tar.gz
> ./binaries/commons-math3-3.6-bin.tar.gz
> ./binaries/commons-math3-3.6.1-bin.tar.gz
>
>
>
> We make the new version folders as you suggested (vary for your
> preferred 3.5 / math3-3.5 vs math-3.5 folder name style)
>
> Adding folders:
> 2.2/
> 3.5/
> 3.6/
> 3.6.1/
>
> - and then (as we've not made new math releases yet) their files
> symlink back, e.g.:
>
> stain@biggie:/tmp/math$ ls -al [23]*/*gz
> lrwxrwxrwx 1 stain stain 37 May 3 10:41
> 2.2/commons-math-2.2-src.tar.gz ->
> ../source/commons-math-2.2-src.tar.gz
> lrwxrwxrwx 1 stain stain 35 May 3 10:41 2.2/commons-math-2.2.tar.gz
> -> ../binaries/commons-math-2.2.tar.gz
> lrwxrwxrwx 1 stain stain 40 May 3 10:43
> 3.5/commons-math3-3.5-bin.tar.gz ->
> ../binaries/commons-math3-3.5-bin.tar.gz
> lrwxrwxrwx 1 stain stain 38 May 3 10:42
> 3.5/commons-math3-3.5-src.tar.gz ->
> ../source/commons-math3-3.5-src.tar.gz
> lrwxrwxrwx 1 stain stain 40 May 3 10:43
> 3.6/commons-math3-3.6-bin.tar.gz ->
> ../binaries/commons-math3-3.6-bin.tar.gz
> lrwxrwxrwx 1 stain stain 38 May 3 10:43
> 3.6/commons-math3-3.6-src.tar.gz ->
> ../source/commons-math3-3.6-src.tar.gz
> lrwxrwxrwx 1 stain stain 42 May 3 11:04
> 3.6.1/commons-math3-3.6.1-bin.tar.gz ->
> ../binaries/commons-math3-3.6.1-bin.tar.gz
> lrwxrwxrwx 1 stain stain 40 May 3 11:04
> 3.6.1/commons-math3-3.6.1-src.tar.gz ->
> ../source/commons-math3-3.6.1-src.tar.gz
>
>
> (Math is a special example that has 4 current versions - for say
> https://dist.apache.org/repos/dist/release/commons/io/ there would
> only be a single folder,
> 2.5)
>
>
>
> Thus the new folders look like this:
>
> stain@biggie:/tmp/math/3.6$ ls -al
> total 0
> drwxrwxr-x 2 stain stain 360 May 3 10:43 .
> drwxrwxr-x 8 stain stain 220 May 3 10:42 ..
> lrwxrwxrwx 1 stain stain 40 May 3 10:43 commons-math3-3.6-bin.tar.gz
> -> ../binaries/commons-math3-3.6-bin.tar.gz
> lrwxrwxrwx 1 stain stain 44 May 3 10:43
> commons-math3-3.6-bin.tar.gz.asc ->
> ../binaries/commons-math3-3.6-bin.tar.gz.asc
> lrwxrwxrwx 1 stain stain 44 May 3 10:43
> commons-math3-3.6-bin.tar.gz.md5 ->
> ../binaries/commons-math3-3.6-bin.tar.gz.md5
> lrwxrwxrwx 1 stain stain 45 May 3 10:43
> commons-math3-3.6-bin.tar.gz.sha1 ->
> ../binaries/commons-math3-3.6-bin.tar.gz.sha1
> lrwxrwxrwx 1 stain stain 37 May 3 10:43 commons-math3-3.6-bin.zip ->
> ../binaries/commons-math3-3.6-bin.zip
> lrwxrwxrwx 1 stain stain 41 May 3 10:43
> commons-math3-3.6-bin.zip.asc ->
> ../binaries/commons-math3-3.6-bin.zip.asc
> lrwxrwxrwx 1 stain stain 41 May 3 10:43
> commons-math3-3.6-bin.zip.md5 ->
> ../binaries/commons-math3-3.6-bin.zip.md5
> lrwxrwxrwx 1 stain stain 42 May 3 10:43
> commons-math3-3.6-bin.zip.sha1 ->
> ../binaries/commons-math3-3.6-bin.zip.sha1
> lrwxrwxrwx 1 stain stain 38 May 3 10:43 commons-math3-3.6-src.tar.gz
> -> ../source/commons-math3-3.6-src.tar.gz
> lrwxrwxrwx 1 stain stain 42 May 3 10:43
> commons-math3-3.6-src.tar.gz.asc ->
> ../source/commons-math3-3.6-src.tar.gz.asc
> lrwxrwxrwx 1 stain stain 42 May 3 10:43
> commons-math3-3.6-src.tar.gz.md5 ->
> ../source/commons-math3-3.6-src.tar.gz.md5
> lrwxrwxrwx 1 stain stain 43 May 3 10:43
> commons-math3-3.6-src.tar.gz.sha1 ->
> ../source/commons-math3-3.6-src.tar.gz.sha1
> lrwxrwxrwx 1 stain stain 35 May 3 10:43 commons-math3-3.6-src.zip ->
> ../source/commons-math3-3.6-src.zip
> lrwxrwxrwx 1 stain stain 39 May 3 10:43
> commons-math3-3.6-src.zip.asc ->
> ../source/commons-math3-3.6-src.zip.asc
> lrwxrwxrwx 1 stain stain 39 May 3 10:43
> commons-math3-3.6-src.zip.md5 ->
> ../source/commons-math3-3.6-src.zip.md5
> lrwxrwxrwx 1 stain stain 40 May 3 10:43
> commons-math3-3.6-src.zip.sha1 ->
> ../source/commons-math3-3.6-src.zip.sha1
>
>
> e.g. the new-style download link pattern would become
>
> http://www.eu.apache.org/dist/commons/math/3.6/commons-math3-3.6-src.tar.gz
> http://www.eu.apache.org/dist/commons/math/3.6/commons-math3-3.6-bin.tar.gz
>
> We then update download pages/templates to use this pattern.
>
>
> For a new release (e.g. commons-math-2.3 or commons-math3-3.7) the
> files would be added directly to their version folders 2.3/ and 3.7/ -
> e.g. they would not exist in binaries/ and source) - when clearing a
> old folder io/2.2/ we would then also clear binaries/*2.2* and
> sources/*2.2*
That is where I have a problem.
If it's OK for MATH 2.3 to only exist in the new layout, why is it not
OK for the current release?
With the above scenario, only MATH 2.2 would be available in both layouts.
MATH 2.1 and earlier would be old only and MATH 2.3+ new only.
I just don't see how it helps to have a single MATH2 version available
in both layouts.
Note that there are quite a few Commons components that are unlikely
to see another release, so providing new-style links for them is a
waste of time and space.
>
> Complete example:
>
> https://paste.apache.org/8MKJ
>
>
> (Note for this example commons-math-2.2 includes
> commons-math-2.2-src.tar.gz and the binary commons-math-2.2.tar.gz
> as we agreed not to rename to -bin on older)
>
>
>
>
>
> --
> 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
