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
30 matches
Mail list logo
