Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

c: Commons Developers List Sent: Tuesday, 30 October 2018 1:33 AM Subject: Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1) > On Oct 29, 2018, at 7:24 AM, Rob Tompkins wrote: > > > >> On Oct 28, 2018, at 8:04 P

Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

__ >> From: Rob Tompkins >> To: Commons Developers List >> Cc: Bruno P. Kinoshita >> Sent: Monday, 29 October 2018 2:49 AM >> Subject: [site] update release process (Was: Re: [VOTE] Release Commons >> Imaging 1.0-alpha1 based on RC1) >> &g

Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

c: Bruno P. Kinoshita > Sent: Monday, 29 October 2018 2:49 AM > Subject: [site] update release process (Was: Re: [VOTE] Release Commons > Imaging 1.0-alpha1 based on RC1) > > > > This is mildly on me for not updating the release docs recently. I’ll put > that on my

Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

: Bruno P. Kinoshita Sent: Monday, 29 October 2018 2:49 AM Subject: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1) This is mildly on me for not updating the release docs recently. I’ll put that on my docket for the week. PS. @Bruno solid work

[site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

This is mildly on me for not updating the release docs recently. I’ll put that on my docket for the week. PS. @Bruno solid work and many thanks for rolling the RC. Cheers, -Rob > On Oct 28, 2018, at 9:35 AM, Gary Gregory wrote: > > Hello Bruno, > > Thank you for preparing the RC. > > MD5

Re: [release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

Am 13.01.2018 um 15:36 schrieb Gilles: > On Sat, 13 Jan 2018 08:48:19 -0500, Rob Tompkins wrote: >> Given that right now we don’t have sufficient votes to release the >> plugin, do folks want me to cancel this vote in leu of the lazy vote >> process cleaning up the nits that folks have found?

Re: [release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

I will find some time to review this weekend. Gary On Jan 13, 2018 6:48 AM, "Rob Tompkins" wrote: > Given that right now we don’t have sufficient votes to release the plugin, > do folks want me to cancel this vote in leu of the lazy vote process > cleaning up the nits that

Re: [release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

On Sat, 13 Jan 2018 08:48:19 -0500, Rob Tompkins wrote: Given that right now we don’t have sufficient votes to release the plugin, do folks want me to cancel this vote in leu of the lazy vote process cleaning up the nits that folks have found? I’m curious since folks don’t seem to have the

[release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

Given that right now we don’t have sufficient votes to release the plugin, do folks want me to cancel this vote in leu of the lazy vote process cleaning up the nits that folks have found? I’m curious since folks don’t seem to have the appetite for this process. > On Jan 11, 2018, at 10:51 PM,

Re: Questions regarding improving the Apache Commons release process.

tool.conf.html >>> >>> Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit : >>>> Stephen, >>>> >>>> I can’t thank you enough for your reply. I’ll take your suggestions and >>>> continue to sandbox around using the maven-release-plugin

Re: Questions regarding improving the Apache Commons release process.

around using the maven-release-plugin as a guideline. >>> >>> All the best and happy holidays, >>> -Rob >>> >>>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly >>>> <stephen.alan.conno...@gmail.com> wrote:> >>>>

Re: [commons-release-plugin] Progress report. (Was: Re: Questions regarding improving the Apache Commons release process.)

Thank you for spearheading making our release process better. One tricky thing to watch out for are components like Lang and DBCP which have folder names on dist that are not the artifact ID. IOW lang vs lang3, dbcp vs dbcp2. Gary On Dec 30, 2017 08:29, "Rob Tompkins" <chtom...@gma

[commons-release-plugin] Progress report. (Was: Re: Questions regarding improving the Apache Commons release process.)

Hello all, I just wanted to let everyone know where I’ve been running lately. I’m writing a new commons component specifically “commons-release-plugin” for the sake of making a maven plugin that adheres to our release process. I’m sandboxing it in my git work area: https://github.com/chtompki

Re: Questions regarding improving the Apache Commons release process.

as a guideline. >> >> All the best and happy holidays, >> -Rob >> >>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly >>> <stephen.alan.conno...@gmail.com> wrote:> >>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins <chtom...@apache.org > <ma

Re: Questions regarding improving the Apache Commons release process.

Hello all, > >> > >> Pardon, maybe this should have gone to your @user list, but why not ping > >> the dev crew. I’ve been playing around the ideas surrounding our fairly > >> manual release process for the components in Commons, and I was hoping > >>

Re: Questions regarding improving the Apache Commons release process.

om> wrote: > > On Tue 26 Dec 2017 at 03:10, Rob Tompkins <chtom...@apache.org > <mailto:chtom...@apache.org>> wrote: > >> Hello all, >> >> Pardon, maybe this should have gone to your @user list, but why not ping >> the dev crew. I’ve been playing aroun

Re: Questions regarding improving the Apache Commons release process.

On 26 December 2017 at 18:48, Matt Sicker wrote: > On 26 December 2017 at 04:27, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> Personally... I see no reason to remove them from going to Nexus staging >> (in fact I have a background plan to add secondary

Re: Questions regarding improving the Apache Commons release process.

On 26 December 2017 at 04:27, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Personally... I see no reason to remove them from going to Nexus staging > (in fact I have a background plan to add secondary signing support to > staging... i’m Waiting to see the Nexus 3 staging APIs

Re: Questions regarding improving the Apache Commons release process.

On Tue 26 Dec 2017 at 03:10, Rob Tompkins <chtom...@apache.org> wrote: > Hello all, > > Pardon, maybe this should have gone to your @user list, but why not ping > the dev crew. I’ve been playing around the ideas surrounding our fairly > manual release process for the compone

Questions regarding improving the Apache Commons release process.

Hello all, Pardon, maybe this should have gone to your @user list, but why not ping the dev crew. I’ve been playing around the ideas surrounding our fairly manual release process for the components in Commons, and I was hoping for some insights. Scripting the version changes isn’t really

Re: [weaver] 1.3 release process

Go for it! Gary On Fri, Sep 30, 2016 at 9:55 AM, Matt Benson wrote: > Just a note to let the community I plan to start rolling release candidates > in the near future. > > Matt > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate,

[weaver] 1.3 release process

Just a note to let the community I plan to start rolling release candidates in the near future. Matt

Re: [DISCUSS] Creating Project for Release Process Testing...

On 14 October 2013 02:21, Ralph Goers ralph.go...@dslextreme.com 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

Re: [DISCUSS] Creating Project for Release Process Testing...

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 seb...@gmail.com wrote: On 14 October 2013 02:21, Ralph Goers

Re: [DISCUSS] Creating Project for Release Process Testing...

On 15 October 2013 17:54, Matt Benson gudnabr...@gmail.com 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

Re: [DISCUSS] Creating Project for Release Process Testing...

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,

Re: [DISCUSS] Creating Project for Release Process Testing...

On 15 October 2013 19:33, Matt Benson gudnabr...@gmail.com 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]

Re: [DISCUSS] Creating Project for Release Process Testing...

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, 2013

Re: [DISCUSS] Creating Project for Release Process Testing...

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 manager can play around with that project and get it right before diving into the real work

Re: [DISCUSS] Creating Project for Release Process Testing...

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 least part

Re: [DISCUSS] Creating Project for Release Process Testing...

the component sites should be maintained. Matt On Oct 13, 2013 12:20 PM, Phil Steitz phil.ste...@gmail.com wrote: 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

Re: [DISCUSS] Creating Project for Release Process Testing...

, 2013, Phil Steitz wrote: 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

Re: [DISCUSS] Creating Project for Release Process Testing...

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

Re: [DISCUSS] Creating Project for Release Process Testing...

On 11 October 2013 05:16, Stefan Bodewig bode...@apache.org 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

Re: [DISCUSS] Creating Project for Release Process Testing...

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 must

Re: [DISCUSS] Creating Project for Release Process Testing...

+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

[DISCUSS] Creating Project for Release Process Testing...

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

Re: [DISCUSS] Creating Project for Release Process Testing...

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 manager can play around with that project and get it right before diving into the real work

Re: [DISCUSS] Creating Project for Release Process Testing...

...@carmanconsulting.com 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 gets staged locally. This way, we can test out changes to the release process and see how they work

Re: [DISCUSS] Creating Project for Release Process Testing...

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 process

Re: [DISCUSS] Creating Project for Release Process Testing...

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

Re: [DISCUSS] Creating Project for Release Process Testing...

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

Re: [DISCUSS] Creating Project for Release Process Testing...

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. Ah sure, excellent idea. You may want two projects then, a simple one and another with modules. Emmanuel Bourg

Re: [DISCUSS] Creating Project for Release Process Testing...

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 manager can play around with that project and get it right

Re: [DISCUSS] Creating Project for Release Process Testing...

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

Re: [DISCUSS] Creating Project for Release Process Testing...

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

Re: [all] Update release process please

On 2013-03-14, Gary Gregory wrote: In the past, I've have felt (disgusted is too strong a word) discouraged from releasing often by the our release process, and it's a 'process' all right. First, I had started to follow: https://commons.apache.org/releases/index.html but finding

Re: [all] Update release process please

releasing often by the our release process, and it's a 'process' all right. First, I had started to follow: https://commons.apache.org/releases/index.html but finding it inadequate, I followed and updated: https://wiki.apache.org/commons/UsingNexus such that I needed little

Re: [RELEASE PROCESS] Stability versus usability

.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4164209.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e

Re: [RELEASE PROCESS] Stability versus usability

a clirr report with the proper information to allow detection of unintended API breakage and may even allow creating IDE plugins to warn about usage. -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html

Re: [RELEASE PROCESS] Stability versus usability

.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional

Re: [RELEASE PROCESS] Stability versus usability

plugins to warn about usage. -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html Sent from the Commons - Dev mailing list archive at Nabble.com

Re: [RELEASE PROCESS] Stability versus usability

Hi Gary! On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory garydgreg...@gmail.com wrote: Personally, I do not like annotations to describe the stability of an API. If it's public I can use it. The next release is binary and/or source compatible, just document how to migrate. No one is forcing me

Re: [RELEASE PROCESS] Stability versus usability

this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev

Re: [RELEASE PROCESS] Stability versus usability

a clirr report with the proper information to allow detection of unintended API breakage and may even allow creating IDE plugins to warn about usage. -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552

Re: [RELEASE PROCESS] Stability versus usability

and for release voting, it gets easier to control that we've not unintentionally screwed it up. Oh, and I do agree on the immutability / thread safety doc. :-) Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability

Re: [RELEASE PROCESS] Stability versus usability

Hi Henri, henrib wrote: It seems to me we have a hard time allowing both stability and usability. Stability of APIs does not contradict usability of the library, at least should not. Some of us are looking for very long term/stable/high-quality solutions because they need to aggregate

Re: [RELEASE PROCESS] Stability versus usability

compatibility requirements. That could by itself provide a workaround for a lot of these issues. Phil Best regards, Henri -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html Sent from the Commons - Dev

Re: [RELEASE PROCESS] Stability versus usability

On 2011-12-04, henrib wrote: When trying to release JEXL 2.1, the API was disrupted and the clirr report was outputing lots of clutter. As the dev, it became very hard to understand whether the change was actually breaking the intended stable API or just some internal methods or class.

Re: [RELEASE PROCESS] Stability versus usability

-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156394.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

dream of a -your favorite IDE here- plugin that warns you when using one of those. If there is an easy / easier practical solution that could serve the same purpose, I'm all for it! -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus

Re: [RELEASE PROCESS] Stability versus usability

. Those annotations and conventions should allow feeding a clirr report with the proper information to allow detection of unintended API breakage and may even allow creating IDE plugins to warn about usage. -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS

Re: [RELEASE PROCESS] Stability versus usability

On 4 December 2011 10:41, henrib hen...@apache.org wrote: Keeping track as it evolves based on feedback; Goal is to allow easy definition, usage and check of stable APIs. +1, agree that we need to be clearer about what the intended external API is. An annotation and a package naming

Re: [RELEASE PROCESS] Stability versus usability

kind? -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4154703.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe

Re: [RELEASE PROCESS] Stability versus usability

a workaround for a lot of these issues. Phil Best regards, Henri -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html Sent from the Commons - Dev mailing list archive at Nabble.com

Re: [RELEASE PROCESS] Stability versus usability

:-) Cheers,   Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com De: Phil Steitz phil.ste...@gmail.com Para: Commons Developers List dev@commons.apache.org Enviadas: Sábado, 3 de Dezembro de 2011 23:22 Assunto: Re: [RELEASE PROCESS] Stability versus

Re: [RELEASE PROCESS] Stability versus usability

On 2011-12-02, henrib wrote: It seems to me we have a hard time allowing both stability and usability. Stability of APIs does not contradict usability of the library, at least should not. I'm glad you say that right at the beginning as the versus in the subject line seems to imply something

Re: [RELEASE PROCESS] Stability versus usability

. Seems like a win-win. Best regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156330.html Sent from the Commons - Dev mailing list archive at Nabble.com

[RELEASE PROCESS] Stability versus usability

minor with no warning We might also use a clear 'internal' sub-package name as a frontier delimiter on the same rule. Thoughts ? Best regards, Henri -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html Sent

Re: [release process] zip and tar.gz included in maven repo?

On Sun, May 1, 2011 at 12:53 PM, Simone Tripodi simonetrip...@apache.org wrote: I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? In contrary, they should, to make use of all the Maven plugins for signing etc. -- I Am What I Am And That's

Re: [release process] zip and tar.gz included in maven repo?

On Sun, May 1, 2011 at 3:55 PM, Simone Tripodi simonetrip...@apache.org wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( So what? I think that's perfectly fine. -- I Am What I Am And That's All What I Yam (Popeye)

Re: [release process] zip and tar.gz included in maven repo?

I don't think (bin|src)-(.zip|.tar.gz) should be part of Maven artifacts on central repo, having them on the distribution servers is enough http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, May 2, 2011 at 1:12 PM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Sun,

Re: [release process] zip and tar.gz included in maven repo?

On Mon, May 2, 2011 at 2:26 PM, Simone Tripodi simonetrip...@apache.org wrote: I don't think (bin|src)-(.zip|.tar.gz) should be part of Maven artifacts on central repo, having them on the distribution servers is enough I don't think doesn't count as a problem that ought to be fixed, isn't it?

Re: [release process] zip and tar.gz included in maven repo?

shall I have to open an Issue so it does? http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, May 2, 2011 at 8:19 PM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Mon, May 2, 2011 at 2:26 PM, Simone Tripodi simonetrip...@apache.org wrote: I don't think

[release process] zip and tar.gz included in maven repo?

extension. Do you have any suggestion to complete correctly the release process? Thanks in advance! Simo mvn stage:copy -Dsource=http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/; \ -Dtarget=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository

Re: [release process] zip and tar.gz included in maven repo?

doesn't work with M3 because the missing wagon-ssh extension. Do you have any suggestion to complete correctly the release process? Thanks in advance! Simo mvn stage:copy -Dsource=http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/; \  -Dtarget=scp://people.apache.org/www

Re: [release process] zip and tar.gz included in maven repo?

Le 01/05/2011 12:53, Simone Tripodi a écrit : Hi again, I just realized that maybe artifacts produced by the assembly plugin should not be attached[1], WDYT? Simo I agree. This is not the case already? - To unsubscribe,

Re: [release process] zip and tar.gz included in maven repo?

Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? Thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg

Re: [release process] zip and tar.gz included in maven repo?

Moreover, after 4 hours the central has not been synched yet... are you aware of any issue? Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sun, May 1, 2011 at 3:55 PM, Simone Tripodi simonetrip...@apache.org wrote: Yes it is :( Problem is that for discovery-0.5, zip

Re: [release process] zip and tar.gz included in maven repo?

On 5/1/11 7:58 AM, Simone Tripodi wrote: Moreover, after 4 hours the central has not been synched yet... are you aware of any issue? It often takes quite a while, but it looks like commons-discovery may not have yet been synched from m2-ibiblio-rsych, so you may need to send a request to

Re: [release process] zip and tar.gz included in maven repo?

On 5/1/11 6:55 AM, Simone Tripodi wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? Thanks in advance, Simo I assume they have been *copied* not moved, right? So there is no

Re: [release process] zip and tar.gz included in maven repo?

On 5/1/11 6:55 AM, Simone Tripodi wrote: Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have been copied to be sync'ed to central repo :'( does someone have an idea how to remove them? I just tried to move the zips and tarballs to my home directory, but could not because the

Re: [release process] zip and tar.gz included in maven repo?

Thanks *a lot* Phil for your kind help. I just executed the commands you suggested me, and dopped *tar.gz* *zip* files, original are still on staged[1] repository Looking forward to see Discovery synched!!! Have a nice day, Simo [1]

Re: [release process] zip and tar.gz included in maven repo?

On 5/1/11 9:18 AM, Simone Tripodi wrote: Thanks *a lot* Phil for your kind help. I just executed the commands you suggested me, and dopped *tar.gz* *zip* files, original are still on staged[1] repository Looking forward to see Discovery synched!!! Have a nice day, Simo [1]

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

Very late, but I've been a tad busy in the new-parent department. Generally I agree with Phil's email. I don't really care though - I recognize that my main pain with Nexus is a) the experience to know not to trust magical systems b) not being full of energy to follow yet another build system

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell flame...@gmail.com wrote: Very late, but I've been a tad busy in the new-parent department. You didn't publish a POM yet, did you? ;-) What I do care about is releasing often. Which is farcical given how few times I've released. I want to

Passwords in Maven settings file [Was: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1]

On 5 April 2011 09:32, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell flame...@gmail.com wrote: [Side note; this is insane: http://maven.apache.org/guides/mini/guide-encryption.html - I vomit every time it's implied I should put passwords in

Re: Passwords in Maven settings file [Was: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1]

On Tue, Apr 5, 2011 at 2:37 AM, sebb seb...@gmail.com wrote: On 5 April 2011 09:32, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell flame...@gmail.com wrote: [Side note; this is insane: http://maven.apache.org/guides/mini/guide-encryption.html -

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On 31 March 2011 04:00, Phil Steitz phil.ste...@gmail.com wrote: On 3/30/11 6:57 PM, sebb wrote: On 31 March 2011 01:38, Phil Steitz phil.ste...@gmail.com wrote: On 3/30/11 4:22 PM, Jochen Wiedmann wrote: On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz phil.ste...@gmail.com wrote: I disagree

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz phil.ste...@gmail.com wrote: And then you need to check the hashes and sigs again since you are now working with downloaded copies of the files that we voted on. Seems much easier and more correct to me to just scp the files to p.a.o., let people

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

with that idea, because that area isn't covered by either Nexus nor the maven-release-plugin. The work that we spend here might even be adopted by other Apache projects. But that wasn't the initial point of the discussion, was it? I thoought the point was to improve the release process. Since we

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On 31 March 2011 12:08, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz phil.ste...@gmail.com wrote: And then you need to check the hashes and sigs again since you are now working with downloaded copies of the files that we voted on. Seems much

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On Mar 31, 2011, at 8:49 AM, sebb wrote: On 31 March 2011 12:08, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz phil.ste...@gmail.com wrote: And then you need to check the hashes and sigs again since you are now working with downloaded copies

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On Thu, Mar 31, 2011 at 5:46 PM, sebb seb...@gmail.com wrote: If they are left in Nexus staging, AFAIK they end up in Maven Central when promoted. And your point is? -- I Am What I Am And That's All What I Yam (Popeye) -

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On 31 March 2011 00:22, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz phil.ste...@gmail.com wrote: I disagree with this.  The most important artifacts are the zips/tars that go to dist/.  These *are* the ASF release.  Nexus makes it *harder* IMO

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On 3/30/11 4:22 PM, Jochen Wiedmann wrote: On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz phil.ste...@gmail.com wrote: I disagree with this. The most important artifacts are the zips/tars that go to dist/. These *are* the ASF release. Nexus makes it *harder* IMO to maintain provenance of

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On 31 March 2011 01:38, Phil Steitz phil.ste...@gmail.com wrote: On 3/30/11 4:22 PM, Jochen Wiedmann wrote: On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz phil.ste...@gmail.com wrote: I disagree with this.  The most important artifacts are the zips/tars that go to dist/.  These *are* the ASF

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

I'm seeing a lot of complaining on these threads but no actual proposal. If the proposal is to move away from Maven/Nexus for a release for all of commons I'll vote -1. OTOH, If some release managers want to do the release some other way I'm not going to force them to use Maven/Nexus. Ralph

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On 3/30/11 6:57 PM, sebb wrote: On 31 March 2011 01:38, Phil Steitz phil.ste...@gmail.com wrote: On 3/30/11 4:22 PM, Jochen Wiedmann wrote: On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz phil.ste...@gmail.com wrote: I disagree with this. The most important artifacts are the zips/tars that go

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

On 3/30/11 7:07 PM, Ralph Goers wrote: I'm seeing a lot of complaining on these threads but no actual proposal. I started the thread with a proposal, which was to standardize on the process documented on the web site. I know you don't like that process and I am not going to insist that we force

  1   2   >