Incidentally I've struggled a bit with the release plugin in the past; have found it a little temperamental. (I ended up not using it when I released xbean as I just couldn't get it to work after following the instructions to the letter). The bits I like though are all that switching of poms, tagging and switching poms back to the snapshot etc. (Checking for SNAPSHOTs is good too).
I wonder if there's some way of patching the release plugin to work with our style of release processes - where the release is created, voted on and then if approved then actually done. The main problem seems to be we need to produce the release on a 'staging area' (such as our home directory), then if it gets voted in, move it to the actual m1/m2 repositories (assuming one day we get a m2 repository we can actually use at apache for incubating projects :-). I guess the current release plugin prepare is fine - its more the perform that we need to split into two parts. Assuming we found the release plugin to be reliable and work for us, we could do a release:prepare, then take the properties file and use it to perform a release:perform-sample which would create a full release but deploy it to our home directories at Apache rather than the real repos. Then after the vote, we do a release:perform which should do exactly the same thing but deploy in the real location? I'd have a warm fuzzier feeling if we just moved the artifacts across though, you never know some gremlin could occur between release:perform-sample and release:perform. So maybe we make release:perform go to our home directories and we have some maven plugin to move a release in our home directory to the real repos? e.g. after a release is performed we do a mvn release:approve which moves from the home directory to the official m1/m2 repos? I guess the use of the release plugin could be completely optional - we could just do mvn deploy which would go to our home directories for non-snapshots; then we have some kinda 'approve' plugin which moves the release in our home directory to the m1/m2 repo? On 7/26/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
True. So we must either: * change our release process to the maven practice, i.e. vote on snapshots and then release * find a nice way to release things and document it. Also note that our release process is somehow problematic. The way I did in ServiceMix and Xbean was to deploy the release to a private remote repository at Apache. But when the release is approved, you have to put the content of the repo in the public Apache repositories (at least for XBean, because ServiceMix and ActiveMQ are still in incubation). But if you just copy things, some metadata on the repository are lost :( From what i heard, maven 2.1 should handle such a release process better, but i'm not sure how. Cheers, Guillaume Nodet On 7/26/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > I actually think the maven 2 release plugin is a bit of pain. It's not > built to follow our release process where we put up release candidates, > hold > a vote, then deploy the release binaries. It also handles the branching > and > tagging very differently. > > On 7/26/06, James Strachan <[EMAIL PROTECTED]> wrote: > > > > Sounds cool with me. I guess once we get to 4.1 we can use the maven 2 > > release plugin to make this kinda stuff easier > > > > On 7/26/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I just recently put up a ActiveMQ 4.0.2 release candidate for vote so > > while > > > it's fresh on my mind I'd like to see if anybody minds if I make a > small > > > tweak to the way we label our snapshot versions. I'd like to either > > change > > > it to 4.0-SNAPSHOT or even 4.0.x-SNAPSHOT. > > > > > > The driver behind this change is that on the 4.0 branch, every time we > > do a > > > release (for example this 4.0.2 release), we have to remember to > > increment > > > the version on the branch on all the poms. It's easy to forget to > > change > > > this and I don't see much value in changing the pom after every > release. > > > > > > -- > > > Regards, > > > Hiram > > > > > > Blog: http://hiramchirino.com > > > > > > > > > > > > -- > > > > James > > ------- > > http://radio.weblogs.com/0112098/ > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > >
-- James ------- http://radio.weblogs.com/0112098/
