Changed the email subject, it seemed more appropriate IMO even though historically its not our favorite topic. Multiple replies below ...
On Sat, Jun 27, 2009 at 7:06 AM, Siegfried Goeschl<[email protected]> wrote: > Hi Sebastian, > > I think this things were discussed a couple of times before and my > understanding of it > > +) we use the M2 release plugin to cut the RC > +) the RC is using the "real" release tag because it is referenced in > the released pom <snip/> Right, but with all said and the current pom(s), the best approach IMO is use RCn tags, and svn cp passing tag to final name. I've done this for a couple of releases, and while some may not be fond of it (having RCn tag in pom) I think folks generally have been understanding about the fact that it allows those who want to use the release plugin to do so (I say this since those votes passed). I intend to continue using the RCn tags with the current parent. Either way RMs choose, this is not a deal breaker when voting AFAIAC. > +) if the vote passes that the RC is the release and we move it just around > > If my view of things is wrong and/or incomplete then please update the > wiki page (http://wiki.apache.org/commons/CreatingReleases) > > Any feedback appreciated > <snap/> Thanks for keeping it updated :-) On Sat, Jun 27, 2009 at 10:34 AM, Jochen Wiedmann<[email protected]> wrote: <snip/> > > I made good experiences with Nexus in my last two releases. I'd > recommend to use it. > > Basically, the process is the same than what you are doing until the > point when the release > is accepted. At that point you are basically done with Nexus. See > > http://maven.apache.org/developers/release/releasing.html > <snap/> +1, we should move in that direction. The parent is still using apache pom v4. It will be better for us to upgrade to v6 and cut a parent release with any other needed changes before On Sun, Jun 28, 2009 at 4:34 PM, Jochen Wiedmann<[email protected]> wrote: > On Sun, Jun 28, 2009 at 5:24 AM, Henri Yandell<[email protected]> wrote: > >> The most important part to consider is 'What can go wrong?'. > > Ok, here's my reply to your question. Assuming that I am forced to > follow the procedure as outlined by you. That means that I am forced > not to use the maven-release-plugin. Consequently, I am forced to do a > lot of manual steps, which would otherwise be completely automated. > The likelyhood that something goes wrong would be dramatically > increased, including production of invalid or corrupt artifacts at any > stage in the process. I had my share of that and I don't want it any > longer. > <snip/> I know that some RMs don't use the release plugin. I do. There is really nothing that forces RMs either way. On Mon, Jun 29, 2009 at 6:14 AM, Mark Struberg<[email protected]> wrote: > > I personally don't get all the discussion here, because this very question > has imho been discussed a lot in the past (on commons and maven lists). > <snip/> +1, having a hard time myself :-) On Mon, Jun 29, 2009 at 3:36 PM, Siegfried Goeschl<[email protected]> wrote: > Hi folks, > > some thoughts along the line ... > > +) I would like to use the M2 release plugin <snip/> +1 > +) I don't mind copying the release tag to a "RCX SVN" tag if the vote fails <snap/> Or having RCn in released pom :-) > +) the <commons.rc.version> is work-around to distinguish multiple RCs <snip/> Yup, and more to do with lack of a solution for the apache m2 repo like Nexus at the time. > +) I know that the release process is not perfect but "perfect is the > enemy of good" > > And my personal point of view - either we settle for one (documented and > accepted) approach or you should positively accept that not all things > are perfect. At the end of the day I want to get a release out of the > door and not let my RC getting killed by endless discussion (btw - the > last time it was the version numbering schema for commons-exec) > <snap/> +1, yes please. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
