You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2016/04/16 01:02:29 UTC
[ALL] Dist layout change to per version directories
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
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
Note: the facility has been implemented in version 1.6 of the build plugin.
This is currently under lazy vote approval; assume no issues will be
available in a few days time.
I intend to use it for the Net and Validator releases.
On 16 April 2016 at 09:36, sebb <se...@gmail.com> wrote:
> On 16 April 2016 at 01:00, James Carman <ja...@carmanconsulting.com> wrote:
>> That definitely seems easier. +1.
>
> Another advantage is that it should make it simpler to automate
> creating the dist/dev staging area from Nexus.
> The staging area could be created as dist/dev/commons/abc/abc-123-RC4.
> There would then be less chance of voting on stale artifacts as each
> RC would have its own area.
>
>> Would that mess up any sort of sync jobs
>> (maven and stuff)?
>
> AFAIK Maven does not know the existing layout, since it varies between projects.
> (The commons build plugin is the only place that does know, and it has
> to be specifically told)
>
> Mirrors will take everything under dist, including dist/commons
>
> I suppose it's possible some 3rd parties may make assumptions about
> the layout, but it's not standard across ASF projects.
>
>> On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory <ga...@gmail.com> wrote:
>>
>>> I am OK with anything that makes releasing easier.
>>>
>>> Gary
>>>
>>> On Fri, Apr 15, 2016 at 4:02 PM, sebb <se...@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
>>> >
>>> >
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
On 16 April 2016 at 01:00, James Carman <ja...@carmanconsulting.com> wrote:
> That definitely seems easier. +1.
Another advantage is that it should make it simpler to automate
creating the dist/dev staging area from Nexus.
The staging area could be created as dist/dev/commons/abc/abc-123-RC4.
There would then be less chance of voting on stale artifacts as each
RC would have its own area.
> Would that mess up any sort of sync jobs
> (maven and stuff)?
AFAIK Maven does not know the existing layout, since it varies between projects.
(The commons build plugin is the only place that does know, and it has
to be specifically told)
Mirrors will take everything under dist, including dist/commons
I suppose it's possible some 3rd parties may make assumptions about
the layout, but it's not standard across ASF projects.
> On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory <ga...@gmail.com> wrote:
>
>> I am OK with anything that makes releasing easier.
>>
>> Gary
>>
>> On Fri, Apr 15, 2016 at 4:02 PM, sebb <se...@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
>> >
>> >
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by James Carman <ja...@carmanconsulting.com>.
That definitely seems easier. +1. Would that mess up any sort of sync jobs
(maven and stuff)?
On Fri, Apr 15, 2016 at 7:26 PM Gary Gregory <ga...@gmail.com> wrote:
> I am OK with anything that makes releasing easier.
>
> Gary
>
> On Fri, Apr 15, 2016 at 4:02 PM, sebb <se...@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
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: [ALL] Dist layout change to per version directories
Posted by Gary Gregory <ga...@gmail.com>.
I am OK with anything that makes releasing easier.
Gary
On Fri, Apr 15, 2016 at 4:02 PM, sebb <se...@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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Dist layout change to per version directories
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 25/04/2016 11:06, sebb a écrit :
> Never suggests it is impossible; however that is not the case.
> It hasn't happened yet, but I can imagine that there might be a reason
> to maintain two parallel release versions.
I agree older branches can keep being maintained, but we'll never bump
the major version number to match the one of the current development
branch. In addition to semantic versioning considerations that would be
really confusing for our users.
> Note that the artifact names themselves use the artifactid.
> So using it in the folder name would be no different.
I'd argue that the -bin and -src artifacts should also not use the
artifactId. That's what I did when I released JEXL 3.0. The result is
much cleaner IMO:
https://dist.apache.org/repos/dist/release/commons/jexl/source/
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 25 Apr 2016 10:06:12 +0100, sebb wrote:
> On 25 April 2016 at 09:13, Emmanuel Bourg <eb...@apache.org> wrote:
>> Le 25/04/2016 03:04, sebb a écrit :
>>
>>> However the distribution naming convention needs to distinguish
>>> between releases using different Java packages.
>>
>> I don't think that's a justified requirement, unless we intent to
>> use
>> the same version with different packages (for example a version 3.5
>> of
>> commons-lang using the old org.apache.commons.lang package, and a
>> version 3.5 using the new org.apache.commons.lang3 package). This
>> will
>> never happen.
>
> Never suggests it is impossible; however that is not the case.
> It hasn't happened yet, but I can imagine that there might be a
> reason
> to maintain two parallel release versions.
>
> Note that the artifact names themselves use the artifactid.
> So using it in the folder name would be no different.
>
>>> So how do you suggest fixing that problem?
>>
>> As I suggested, by not using the artifactId. The options are:
>> 1. [component]-[version]/
>> 2. [version]/
>>
>> The option 2 has my preference (the path already contains the name
>> of
>> the component, no need to repeat it).
I also choose option 2.
[And option 1 is a confusing hybrid.]
Gilles
> There are occasions when having the component name can be useful.
> For example when checking out the tag for votes.
> Possibly less of an issue for the dist tree, but I found it a big
> nuisance when checking out SVN tags for multiple votes.
>
>> Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
On 25 April 2016 at 09:13, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 25/04/2016 03:04, sebb a écrit :
>
>> However the distribution naming convention needs to distinguish
>> between releases using different Java packages.
>
> I don't think that's a justified requirement, unless we intent to use
> the same version with different packages (for example a version 3.5 of
> commons-lang using the old org.apache.commons.lang package, and a
> version 3.5 using the new org.apache.commons.lang3 package). This will
> never happen.
Never suggests it is impossible; however that is not the case.
It hasn't happened yet, but I can imagine that there might be a reason
to maintain two parallel release versions.
Note that the artifact names themselves use the artifactid.
So using it in the folder name would be no different.
>> So how do you suggest fixing that problem?
>
> As I suggested, by not using the artifactId. The options are:
> 1. [component]-[version]/
> 2. [version]/
>
> The option 2 has my preference (the path already contains the name of
> the component, no need to repeat it).
There are occasions when having the component name can be useful.
For example when checking out the tag for votes.
Possibly less of an issue for the dist tree, but I found it a big
nuisance when checking out SVN tags for multiple votes.
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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
Re: [ALL] Dist layout change to per version directories
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 25/04/2016 03:04, sebb a écrit :
> However the distribution naming convention needs to distinguish
> between releases using different Java packages.
I don't think that's a justified requirement, unless we intent to use
the same version with different packages (for example a version 3.5 of
commons-lang using the old org.apache.commons.lang package, and a
version 3.5 using the new org.apache.commons.lang3 package). This will
never happen.
> So how do you suggest fixing that problem?
As I suggested, by not using the artifactId. The options are:
1. [component]-[version]/
2. [version]/
The option 2 has my preference (the path already contains the name of
the component, no need to repeat it).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
On 18 April 2016 at 12:22, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 18/04/2016 12:56, sebb a écrit :
>
>> Why is that?
>
> Because there is no reason to use the Maven artifactId here, the
> distribution directory isn't a Maven repository.
However the distribution naming convention needs to distinguish
between releases using different Java packages.
Since there must be a 1-1 mapping between Maven gid+aid and Java
packages, using the Maven aid is convenient.
Otherwise we would need to define a different naming convention for
the dist archives.
> That's the same
> reasoning for the -bin and -src files, commons-lang3-3.4 can be mistaken
> for commons-lang 3.3.4.
So how do you suggest fixing that problem?
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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
Re: [ALL] Dist layout change to per version directories
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 18/04/2016 12:56, sebb a écrit :
> Why is that?
Because there is no reason to use the Maven artifactId here, the
distribution directory isn't a Maven repository. That's the same
reasoning for the -bin and -src files, commons-lang3-3.4 can be mistaken
for commons-lang 3.3.4.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
On 18 April 2016 at 07:53, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 16/04/2016 01:02, sebb a écrit :
>
>> 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].*
>
> It we change the layout I'd prefer using the component name instead of
> the artifactId as the base of the directory name:
>
> lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
> lang/commons-lang-3.4/commons-lang3-3.4-[bin|src].*
Why is that?
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
On 18 April 2016 at 10:59, Gilles <gi...@harfang.homelinux.org> wrote:
> On Mon, 18 Apr 2016 10:45:28 +0100, Stian Soiland-Reyes wrote:
>>
>> We might also want to include the "apache-" file prefix for trademark
>> reasons - as advocated to all incubator projects.
>>
>> e.g.
>>
>> /commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz
>>
>
> That certainly makes a lot of sense, also to avoid potential name clashes.
>
> Can it be added automatically to the artefacts, i.e. without requiring
> that the "id" be changed?
That's a separate issue, please start a new e-mail thread.
> Gilles
>
>
>> On 18 April 2016 at 10:40, Gilles <gi...@harfang.homelinux.org> wrote:
>>>
>>> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>>>
>>>>
>>>> Le 18/04/2016 10:48, Gilles a écrit :
>>>>
>>>>> IIRC, I was once corrected that this is not the component's name (which
>>>>> in this case would be "Apache Commons Lang").
>>>>
>>>>
>>>>
>>>> That's consistent with the site URL though:
>>>>
>>>> http://commons.apache.org/proper/commons-lang/
>>>
>>>
>>>
>>> I know; and from a purely aesthetics ;-) POV, I also prefer a reference
>>> to the "component" rather than the "id" which is a concatenation (of
>>> a name and a version) that exists for practical reasons.
>>>
>>> But isn't the change also for a practical reason, namely to avoid
>>> confusing artefacts?
>>>
>>> Hence I thought that the focus should be on the "id", contrary to e.g.
>>> the web site whose primary focus is to document the "component".
>>>
>>>>
>>>> An alternative would be to use the version only:
>>>>
>>>> lang/2.6/commons-lang-2.6-[bin|src].*
>>>> lang/3.4/commons-lang3-3.4-[bin|src].*
>>>
>>>
>>>
>>> Perhaps. It really depends on the issues which the change is trying
>>> to solve; the new scheme should be a solution that does not create
>>> new confusions.
>>>
>>> Gilles
>>>
>>>
>>>> Emmanuel Bourg
>>>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [ALL] Dist layout change to per version directories
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 18 Apr 2016 10:45:28 +0100, Stian Soiland-Reyes wrote:
> We might also want to include the "apache-" file prefix for trademark
> reasons - as advocated to all incubator projects.
>
> e.g.
>
> /commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz
>
That certainly makes a lot of sense, also to avoid potential name
clashes.
Can it be added automatically to the artefacts, i.e. without requiring
that the "id" be changed?
Gilles
> On 18 April 2016 at 10:40, Gilles <gi...@harfang.homelinux.org>
> wrote:
>> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>>
>>> Le 18/04/2016 10:48, Gilles a écrit :
>>>
>>>> IIRC, I was once corrected that this is not the component's name
>>>> (which
>>>> in this case would be "Apache Commons Lang").
>>>
>>>
>>> That's consistent with the site URL though:
>>>
>>> http://commons.apache.org/proper/commons-lang/
>>
>>
>> I know; and from a purely aesthetics ;-) POV, I also prefer a
>> reference
>> to the "component" rather than the "id" which is a concatenation (of
>> a name and a version) that exists for practical reasons.
>>
>> But isn't the change also for a practical reason, namely to avoid
>> confusing artefacts?
>>
>> Hence I thought that the focus should be on the "id", contrary to
>> e.g.
>> the web site whose primary focus is to document the "component".
>>
>>>
>>> An alternative would be to use the version only:
>>>
>>> lang/2.6/commons-lang-2.6-[bin|src].*
>>> lang/3.4/commons-lang3-3.4-[bin|src].*
>>
>>
>> Perhaps. It really depends on the issues which the change is trying
>> to solve; the new scheme should be a solution that does not create
>> new confusions.
>>
>> Gilles
>>
>>
>>> Emmanuel Bourg
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by Stian Soiland-Reyes <st...@apache.org>.
We might also want to include the "apache-" file prefix for trademark
reasons - as advocated to all incubator projects.
e.g.
/commons/lang/3.4/apache-commons-lang3-3.4-src.tar.gz
On 18 April 2016 at 10:40, Gilles <gi...@harfang.homelinux.org> wrote:
> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>
>> Le 18/04/2016 10:48, Gilles a écrit :
>>
>>> IIRC, I was once corrected that this is not the component's name (which
>>> in this case would be "Apache Commons Lang").
>>
>>
>> That's consistent with the site URL though:
>>
>> http://commons.apache.org/proper/commons-lang/
>
>
> I know; and from a purely aesthetics ;-) POV, I also prefer a reference
> to the "component" rather than the "id" which is a concatenation (of
> a name and a version) that exists for practical reasons.
>
> But isn't the change also for a practical reason, namely to avoid
> confusing artefacts?
>
> Hence I thought that the focus should be on the "id", contrary to e.g.
> the web site whose primary focus is to document the "component".
>
>>
>> An alternative would be to use the version only:
>>
>> lang/2.6/commons-lang-2.6-[bin|src].*
>> lang/3.4/commons-lang3-3.4-[bin|src].*
>
>
> Perhaps. It really depends on the issues which the change is trying
> to solve; the new scheme should be a solution that does not create
> new confusions.
>
> Gilles
>
>
>> Emmanuel Bourg
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [ALL] Dist layout change to per version directories
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
> Le 18/04/2016 10:48, Gilles a écrit :
>
>> IIRC, I was once corrected that this is not the component's name
>> (which
>> in this case would be "Apache Commons Lang").
>
> That's consistent with the site URL though:
>
> http://commons.apache.org/proper/commons-lang/
I know; and from a purely aesthetics ;-) POV, I also prefer a reference
to the "component" rather than the "id" which is a concatenation (of
a name and a version) that exists for practical reasons.
But isn't the change also for a practical reason, namely to avoid
confusing artefacts?
Hence I thought that the focus should be on the "id", contrary to e.g.
the web site whose primary focus is to document the "component".
>
> An alternative would be to use the version only:
>
> lang/2.6/commons-lang-2.6-[bin|src].*
> lang/3.4/commons-lang3-3.4-[bin|src].*
Perhaps. It really depends on the issues which the change is trying
to solve; the new scheme should be a solution that does not create
new confusions.
Gilles
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 18/04/2016 10:48, Gilles a écrit :
> IIRC, I was once corrected that this is not the component's name (which
> in this case would be "Apache Commons Lang").
That's consistent with the site URL though:
http://commons.apache.org/proper/commons-lang/
An alternative would be to use the version only:
lang/2.6/commons-lang-2.6-[bin|src].*
lang/3.4/commons-lang3-3.4-[bin|src].*
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 18 Apr 2016 08:53:10 +0200, Emmanuel Bourg wrote:
> Le 16/04/2016 01:02, sebb a écrit :
>
>> 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].*
>
> It we change the layout I'd prefer using the component name instead
> of
> the artifactId as the base of the directory name:
>
> lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
> lang/commons-lang-3.4/commons-lang3-3.4-[bin|src].*
^^^^^^^^^^^^
IIRC, I was once corrected that this is not the component's name (which
in this case would be "Apache Commons Lang").
Moreover, it might be confusing to have different "basenames" (one
for locating this directory and another for locating the artefacts
through a system such as maven).
Gilles
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 16/04/2016 01:02, sebb a écrit :
> 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].*
It we change the layout I'd prefer using the component name instead of
the artifactId as the base of the directory name:
lang/commons-lang-2.6/commons-lang-2.6-[bin|src].*
lang/commons-lang-3.4/commons-lang3-3.4-[bin|src].*
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by Stian Soiland-Reyes <st...@apache.org>.
Because e.g. Math 2.2 was released on 2013-03-03 - a "re-release" of
2.2 at a new location is unexpected - at least if the old location
goes 404.
You are right that my approach would not make 2.1 available in the new
layout - which I think there is not much point in as naturally there
are other inconsistencies across components and filenames for any code
historian browsing https://archive.apache.org/dist/commons/
The goal of my approach was just ensuring that the latest version of
every commons component is available in the new layout (consistency,
as raised by Gilles) - without breaking the active download links on
the mirrors for existing versions that have not (yet or ever) been
replaced.
Practically using symlinks on dist.apache.org in SVN is probably an
easier change to implement as you don't need to re-upload 500 MB or
script thousands of svn cp commands (and check they all worked).
Just my take - I'm not insisting on this - go ahead and break the web
:) At least then the new layout will be picked up quickly..
On 3 May 2016 at 16:18, sebb <se...@gmail.com> wrote:
> 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 <se...@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-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
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
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 <se...@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-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
Re: [ALL] Dist layout change to per version directories
Posted by Stian Soiland-Reyes <st...@apache.org>.
Trying to summarize here.. :)
On 25 April 2016 at 10:49, sebb <se...@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*
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
On 25 April 2016 at 10:13, Stian Soiland-Reyes <st...@apache.org> wrote:
> On 21 April 2016 at 12:06, sebb <se...@gmail.com> wrote:
>
>> Note that once we have released (say) NET 3.5, the downloads for NET
>> 3.4 need to be removed from the mirrors.
>> So the only place that the links will then exist is in the archives.
>>
>> Unless we also set up links for every past release in every Commons
>> component, there is going to be a discontinuity at some point in the
>> naming convention.
>>
>> Seems to me we either accept that we cannot change the names ever, or
>> we accept that downstream users will need to change their URLs.
>>
>> They have to change the URL anyway when a new release is made.
>> 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?
> so I initially suggested a simpler approach, we only do the new
> layout for new releases - as they would come with an equivalent
> release email etc - however Gilles suggested we do the change for all
> components at once - which I admit gives greater consistency but could
> also break many downstream packaging in one go unless we do
> consistency symlinks **for the transitionary versions**. (On the
> other side that would be a "everything breaks at once" event rather
> than "every component download script breaks bit by bit over the next
> years)
Nor do I understand how it helps to have transition links unless
*every* release has a link.
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?
In any case where components change packages the artifact name will
change; I don't see how this is any different.
>
>
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 21 April 2016 at 12:06, sebb <se...@gmail.com> wrote:
> Note that once we have released (say) NET 3.5, the downloads for NET
> 3.4 need to be removed from the mirrors.
> So the only place that the links will then exist is in the archives.
>
> Unless we also set up links for every past release in every Commons
> component, there is going to be a discontinuity at some point in the
> naming convention.
>
> Seems to me we either accept that we cannot change the names ever, or
> we accept that downstream users will need to change their URLs.
>
> They have to change the URL anyway when a new release is made.
> Does it really matter if the URL changes more than just a version string?
Yes, so I initially suggested a simpler approach, we only do the new
layout for new releases - as they would come with an equivalent
release email etc - however Gilles suggested we do the change for all
components at once - which I admit gives greater consistency but could
also break many downstream packaging in one go unless we do
consistency symlinks **for the transitionary versions**. (On the
other side that would be a "everything breaks at once" event rather
than "every component download script breaks bit by bit over the next
years)
--
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
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
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.
>
>
I don't thiink it helps to provide links for the existing releases.
Note that once we have released (say) NET 3.5, the downloads for NET
3.4 need to be removed from the mirrors.
So the only place that the links will then exist is in the archives.
Unless we also set up links for every past release in every Commons
component, there is going to be a discontinuity at some point in the
naming convention.
Seems to me we either accept that we cannot change the names ever, or
we accept that downstream users will need to change their URLs.
They have to change the URL anyway when a new release is made.
Does it really matter if the URL changes more than just a version string?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by sebb <se...@gmail.com>.
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 <gi...@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" <gi...@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" <se...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Dist layout change to per version directories
Posted by Stian Soiland-Reyes <st...@apache.org>.
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 <gi...@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" <gi...@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" <se...@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
Re: [ALL] Dist layout change to per version directories
Posted by Gilles <gi...@harfang.homelinux.org>.
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" <gi...@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" <se...@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
Re: [ALL] Dist layout change to per version directories
Posted by Stian Soiland-Reyes <st...@apache.org>.
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" <gi...@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" <se...@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
>
>
Re: [ALL] Dist layout change to per version directories
Posted by Gilles <gi...@harfang.homelinux.org>.
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" <se...@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
Re: [ALL] Dist layout change to per version directories
Posted by Stian Soiland-Reyes <st...@apache.org>.
+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.
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" <se...@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
>
>