This conversation turns on a classic dilemma in release management. 1. The important thing is to ship exactly the bits that have been tested. Prepare a package, give it to QA. If they like it, ship it. If they don't, rinse, lather, and repeat.
2. The important thing is to never, ever, ever create an artifact named 'release x.y' until *after* QA has approved it. Followers of the second religion like to rename things. They like to build things that are labelled 'release candidate N', and then use some surgical instrument or another to rename at the very end. 'Build numbers' as used by Microsoft (and supported in Maven) are a sop to the #2 committee. If every build has a unique number, you can start labelling something 'release 5' at an early phase in the release process, and detect escaped early components via build numbers. Maven is not very friendly to the followers of tendency #2. Maven aids and abets you in injecting the version number all over the place. If you want the package to be called 'release 5', you have to run the build as 'release 5'. If you want it to be called 'release 5 candidate 1', you call it that -- and you're stuck with it. Snapshots are a red herring, in my opinion. Since they don't correspond to a tag, they don't make anyone happy. In environments that follow the tendency of #2, I would suggest asking yourself why you are using a maven repository *at all* when pushing releases to QA and then out the door. If you are using the assembly plugin, why not turn off 'attaching' altogether. That means that nothing goes onto the repo until someone puts it there (with, say, the deploy plugin by hand). So, you can set the version to a release version, run a build, keep the results in a secret place where only QA can get to them, and only burn white straw and push them out when QA approves them. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
