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

_ From: Rob Tompkins To: Bruno P. Kinoshita Cc: 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: >

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) >>

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

gt; 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) > > > > This is mildly on me for not updating the release docs recently. I’ll put > that o

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

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) 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

[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 a

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? I’m

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 folks have found? I’m

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 appeti

[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, G

Re: Questions regarding improving the Apache Commons release process.

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 as a guideline. >>>> >>>> All the best and happy holi

Re: Questions regarding improving the Apache Commons release process.

deline. >>> >>> All the best and happy holidays, >>> -Rob >>> >>>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly >>>> wrote:> >>>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins > <mailto:chtom...@apache.org>> w

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" wrote: &

[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.

gt;> All the best and happy holidays, >> -Rob >> >>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly >>> wrote:> >>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins <mailto:chtom...@apache.org>> wrote: >>>> Hello all, >>>>

Re: Questions regarding improving the Apache Commons release process.

d 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. > >> > >

Re: Questions regarding improving the Apache Commons release process.

t 03:10, Rob Tompkins <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 around the ideas surrounding our fairly >> manual release process for t

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 signing support to >> st

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 befor

Re: Questions regarding improving the Apache Commons release process.

On Tue 26 Dec 2017 at 03:10, Rob Tompkins 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 components in Commons, and I was ho

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, Second Edition

[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...

>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

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

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

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

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 wrote: > On 14 October 2013 02:21, Ralph Goers wrote: > > > > On Oct 13, 2

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

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

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

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

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 tho

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

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

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 creat

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

s. On Sunday, October 13, 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 do

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

nity among the component sites should be maintained. Matt On Oct 13, 2013 12:20 PM, "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

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 >&g

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

n 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 >>&

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

aps 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 int

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

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 tho

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

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 fairl

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

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 proces

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 futi

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 re

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 recoll

Re: [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

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

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 c

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 volunteeri

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

his 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. > > I'm not sure to see the need for this. There is no doubt Git is sui

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

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

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. I'm not sure to see the need for this. There is no doubt Git is suitable for releasing our components. I just walked dow

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

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 gets staged locally. This way, we >> can test out changes t

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

t; > 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 a

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

th 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. > >

[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 n

Re: [all] Update release process please

gt; > 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 it inadequate, I followed and updated: > > > https://wiki

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/relea

Re: [RELEASE PROCESS] Stability versus usability

p://apache-commons.680414.n4.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 F

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 aggre

Re: [RELEASE PROCESS] Stability versus usability

ng with the API contract 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-PROCE

Re: [RELEASE PROCESS] Stability versus usability

nded but are subject to change between versions without >> > @deprecated annotations. >> > >> > Those annotations and conventions should allow feeding a clirr report >> with >> > the proper information to allow detection of unintended API breakage and >&g

Re: [RELEASE PROCESS] Stability versus usability

those are not part of the "public" API. They >> can >> > be used and extended but are subject to change between versions without >> > @deprecated annotations. >> > >> > Those annotations and conventions should allow feeding

Re: [RELEASE PROCESS] Stability versus usability

Hi Gary! On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory 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 to upgrade. > If I u

Re: [RELEASE PROCESS] Stability versus usability

> @deprecated annotations. > > > > 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 us

Re: [RELEASE PROCESS] Stability versus usability

formation 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-tp4150322p41565

Re: [RELEASE PROCESS] Stability versus usability

ions. > > 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:

Re: [RELEASE PROCESS] Stability versus usability

On 4 December 2011 10:41, henrib 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 convention allow the p

Re: [RELEASE PROCESS] Stability versus usability

precated annotations. 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

Re: [RELEASE PROCESS] Stability versus usability

/methods to find those @internal. One could even 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.68041

Re: [RELEASE PROCESS] Stability versus usability

in context: http://apache-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...@commo

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

asy baby step that I could personally get behind - and actually > need in [math] - is adopting the .internal package name convention > for classes that need to be public because they are used in multiple > packages, but which are not intended for use by external > applications and effec

Re: [RELEASE PROCESS] Stability versus usability

preserve innovative contributions and provides a clearer view of the stable contract. 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-tp4150322p415633

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 somethi

Re: [RELEASE PROCESS] Stability versus usability

eers,   Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com De: Phil Steitz Para: Commons Developers List Enviadas: Sábado, 3 de Dezembro de 2011 23:22 Assunto: Re: [RELEASE PROCESS] Stability versus usability On 12/2/11 3:45 PM, henrib wrote: > It seems

Re: [RELEASE PROCESS] Stability versus usability

ackages, but which are not intended for use by external applications and effectively exempt from version 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://apa

Re: [RELEASE PROCESS] Stability versus usability

some 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 unsubs

[RELEASE PROCESS] Stability versus usability

version but may change in each 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-vers

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 wrote: > On Mon, May 2, 2011 at 2:26 PM, Simone Tripodi > wrote: > >> I don't think (bin|src)-(.zip|.tar.gz) should be part of Maven >> ar

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

On Mon, May 2, 2011 at 2:26 PM, Simone Tripodi 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? -- I Am What I A

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 wrote: > On Sun, May 1, 2011 at 3:55 PM, S

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

On Sun, May 1, 2011 at 3:55 PM, 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 :'( 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?

On Sun, May 1, 2011 at 12:53 PM, Simone Tripodi 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 All What I Yam (Popeye

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] > http:/

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] http://people.apache.org/builds/commons/discovery/0.5/RC2/staged

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?

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

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 repos

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 wrote: > Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have > been co

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?

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, e-mail

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

the command 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/discover

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

he 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/people.apache.o

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 wrote: > On 5 April 2011 09:32, Jochen Wiedmann wrote: >> On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell 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 Maven settings file [Was: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1]

On 5 April 2011 09:32, Jochen Wiedmann wrote: > On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell 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 the Maven settings >> file] > > Totall

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

On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell 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 release every month.

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 ch

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

On Thu, Mar 31, 2011 at 5:46 PM, sebb 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) - To unsubscribe,

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 wrote: >> On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz 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. >>> S

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

On 31 March 2011 12:08, Jochen Wiedmann wrote: > On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz 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

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

py, but would everyone else? > > Nothing wrong 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

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

On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz 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 vote on them and *m

  1   2   3   >