>From the time I spent recently perusing their API docs, I would guess from
the fact that they qualify the URL scheme with a "1" version, that they
will preserve compatibility indefinitely. If they alter their API I
presume it will use a different version ID on the URL.
Matt
On Tue, Oct 15, 201
On 15 October 2013 19:33, Matt Benson wrote:
> Asked on #asfinfra and got the link from bdemers: [1]. He says it will
> change to [2] whenever Nexus is upgraded.
Thanks!
Just to clarify: is it just the link that will change, or will the API
change as well?
> Matt
> [1]
> https://repository.apa
Asked on #asfinfra and got the link from bdemers: [1]. He says it will
change to [2] whenever Nexus is upgraded.
Matt
[1]
https://repository.apache.org/nexus-core-documentation-plugin/core/docs/index.html
[2]
https://repository.apache.org/nexus-restlet1x-plugin/default/docs/index.html
On Tue,
On 15 October 2013 17:54, Matt Benson wrote:
> We should probably investigate whether Nexus's REST APIs would be of any
> use here; seemingly they would make it much more difficult to inadvertently
> delete the wrong file(s).
I did try to find out about them.
Unfortunately they are not documented
We should probably investigate whether Nexus's REST APIs would be of any
use here; seemingly they would make it much more difficult to inadvertently
delete the wrong file(s).
Matt
On Tue, Oct 15, 2013 at 11:33 AM, sebb wrote:
> On 14 October 2013 02:21, Ralph Goers wrote:
> >
> > On Oct 13, 2
On 14 October 2013 02:21, Ralph Goers wrote:
>
> On Oct 13, 2013, at 4:31 PM, sebb wrote:
>
>> Recently, I found that the Maven project RMs don't bother removing these.
>> So the files are released to Maven Central with the rest.
>> I assume that the Maven Central administrators don't care about t
On Oct 13, 2013, at 4:31 PM, sebb wrote:
> Recently, I found that the Maven project RMs don't bother removing these.
> So the files are released to Maven Central with the rest.
> I assume that the Maven Central administrators don't care about the
> extra space needed.
>
> Now ASF source releases
On 11 October 2013 10:23, Emmanuel Bourg wrote:
> Le 11/10/2013 01:35, Matt Benson a écrit :
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons. I think it would be immensely
>> helpful for those of us who have been at least p
On 11 October 2013 05:16, Stefan Bodewig wrote:
> On 2013-10-11, Matt Benson wrote:
>
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons. I think it would be immensely
>> helpful for those of us who have been at least part way
Le 12/10/2013 10:07, Olivier Lamy a écrit :
> Why removing those files? It's is strictly forbidden by any Apache
> rules to have those?
No, but it just clutters Maven Central. The .asc file contains a signed
hash of the file, there is no need to have two additional hashes of a hash.
> why creat
Phil, I'm for whatever makes it easier. In the new release test project,
let's start "green field" and see what we come up with. If we see enough
boilerplate to merit a parent, then we will extract those bits and make
one. If not, then it's every component for themselves.
On Sunday, October 13,
I understand your frustration, Phil, particularly if you're the type who
has never liked the flavor of the Maven kool-aid... I know I struggled
fruitlessly for years against Maven! However, the biggest benefit I see to
the parent pom is the site management. I can't justify us propping up some
cust
On 10/11/13 3:53 AM, Gilles wrote:
> On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
>> We're all still talking about the release process, but in all
>> honesty I've
>> not done it for several years at Commons. I think it would be
>> immensely
>> helpful for those of us who have been at lea
JIRA created:
https://issues.apache.org/jira/browse/INFRA-6859
On Sun, Oct 13, 2013 at 4:17 AM, Siegfried Goeschl
wrote:
> +1 on that
>
> I did a few releases over the year and had ALWAYS issues - for me the
> biggest obstacles are
>
> * getting a positive vote on a RC (that's a different story
+1 on that
I did a few releases over the year and had ALWAYS issues - for me the
biggest obstacles are
* getting a positive vote on a RC (that's a different story)
* getting the release out of the door - a test project would help
immensely since I can blow it up without any consequences
Che
On 11 October 2013 20:23, Emmanuel Bourg wrote:
> Le 11/10/2013 01:35, Matt Benson a écrit :
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons. I think it would be immensely
>> helpful for those of us who have been at least p
On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
We're all still talking about the release process, but in all honesty
I've
not done it for several years at Commons. I think it would be
immensely
helpful for those of us who have been at least part way through the
process
fairly recently
Le 11/10/2013 01:35, Matt Benson a écrit :
> We're all still talking about the release process, but in all honesty I've
> not done it for several years at Commons. I think it would be immensely
> helpful for those of us who have been at least part way through the process
> fairly recently (Emmanue
+1 from me for anything that makes the release process sane.
I'd be committing again if preparing a release was simple enough. As it is,
I don't have the blocks of time needed to push out a release and committing
to projects with no apparent release manager becomes an exercise in
futility.
Hen
On 2013-10-11, Matt Benson wrote:
> We're all still talking about the release process, but in all honesty I've
> not done it for several years at Commons. I think it would be immensely
> helpful for those of us who have been at least part way through the process
> fairly recently (Emmanuel, Gary,
We're all still talking about the release process, but in all honesty I've
not done it for several years at Commons. I think it would be immensely
helpful for those of us who have been at least part way through the process
fairly recently (Emmanuel, Gary, others?) to present your recollections of
I need to have Matt start writing my emails. What he said! ;) I'm too
impatient to be so eloquent.
On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson wrote:
> Emmanuel,
> IMO this goes beyond the SCM question. Commons releases are painful
> (you've just been through the process; do you disagree?)
Or just a multi-module only and do the worst case scenario.
On Thu, Oct 10, 2013 at 11:41 AM, Emmanuel Bourg wrote:
> Le 10/10/2013 17:36, James Carman a écrit :
>> This isn't to address Git. This is just in-general a little sandbox
>> that folks can use to either test out change to the release
Le 10/10/2013 17:36, James Carman a écrit :
> This isn't to address Git. This is just in-general a little sandbox
> that folks can use to either test out change to the release process
> (or documentation) or just have a go at being a release manager before
> actually volunteering. Anyone would be
Emmanuel,
IMO this goes beyond the SCM question. Commons releases are painful
(you've just been through the process; do you disagree?) and I submit that
this fact is the reason it takes so long for any of us to muster up the
courage to commit himself to diving into that process with no real idea
This isn't to address Git. This is just in-general a little sandbox
that folks can use to either test out change to the release process
(or documentation) or just have a go at being a release manager before
actually volunteering. Anyone would be free to cut a release at any
time.
On Thu, Oct 10
Le 10/10/2013 17:24, James Carman a écrit :
> Why don't we create a real project that we can cut real releases on to
> test our release procedures? Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally. This way, we
> can test out changes to the release proc
Fine with me! I'm good with that. I just was worried folks would
think of it as "cluttering" central
On Thu, Oct 10, 2013 at 11:29 AM, Gary Gregory wrote:
> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
> wrote:
>> Why don'
Once it's properly in Nexus, is there any reason to push all the way to
central?
Matt
On Thu, Oct 10, 2013 at 10:29 AM, Gary Gregory wrote:
> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
> wrote:
> > Why don't we create a r
Nice idea, but push it to central to test the whole chain.
G
On Thu, Oct 10, 2013 at 11:24 AM, James Carman
wrote:
> Why don't we create a real project that we can cut real releases on to
> test our release procedures? Perhaps we can set it up so that it
> doesn't sync with central and just get
Why don't we create a real project that we can cut real releases on to
test our release procedures? Perhaps we can set it up so that it
doesn't sync with central and just gets staged locally. This way, we
can test out changes to the release process and see how they work.
Also, a new release manag
31 matches
Mail list logo
