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 i
On 3 May 2016 at 11:13, Stian Soiland-Reyes wrote:
> Trying to summarize here.. :)
>
> On 25 April 2016 at 10:49, sebb 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?
>
>
Trying to summarize here.. :)
On 25 April 2016 at 10:49, sebb 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
${ve
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 maj
On 25 April 2016 at 10:13, Stian Soiland-Reyes wrote:
> On 21 April 2016 at 12:06, sebb 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
On Mon, 25 Apr 2016 10:06:12 +0100, sebb wrote:
On 25 April 2016 at 09:13, Emmanuel Bourg 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,
On 21 April 2016 at 12:06, sebb 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
>
On 25 April 2016 at 09:13, Emmanuel Bourg 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 versio
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
comm
On 18 April 2016 at 12:22, Emmanuel Bourg 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
On 18 April 2016 at 10:43, Stian Soiland-Reyes 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 help
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
-
On 18 April 2016 at 07:53, 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 o
Adding -bin to artifact names is a separate issue, please start a new thread.
On 18 April 2016 at 10:43, Stian Soiland-Reyes 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
On 18 April 2016 at 10:59, Gilles 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
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
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 wrote:
> On Mon, 18 Apr 2016 11:18:49 +0200, Emmanuel Bourg wrote:
>>
>> Le 18/
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 onl
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/prope
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 thr
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
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 permali
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
t
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.
+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 art
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
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 wrote:
> On 16 April 2016 at 01:00
On 16 April 2016 at 01:00, James Carman 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
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 wrote:
> I am OK with anything that makes releasing easier.
>
> Gary
>
> On Fri, Apr 15, 2016 at 4:02 PM, sebb wrote:
>
> > The dist layout currently splits
I am OK with anything that makes releasing easier.
Gary
On Fri, Apr 15, 2016 at 4:02 PM, sebb 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 mo
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
31 matches
Mail list logo
