> So if I understand correctly you want to use SNAPSHOTs because: > - you don't want the artifact to end up in the "releases"-repository yes,
correct > because QA needs to be done first Not quite - occasionally projects (still in development state but nearing its end) engage formal internal test teams to conduct tests against what they delivered (these tests involve performance, integration as well as functional tests) All this takes place in an *non* locked down SIT env. Our formal Archiva release repository is technically not used for other than resources that is deemed well behaved that passed internal unit tests, system integration and in some cases systems that have gone through formal tests by test teams that received a signed off by the internal test team. Once a delivery has been signed off the official release id done (into our releases repo) - this release is then pushed out to the locked down UAT env where the business perform functional tests and once happy and a sign off have been received that same release is then pushed into PROD. So in effect our "releases" repo is only used for UAT and PROD. Releasing a snapshot is a convenient one but I think a snapshot could be viewed in two different ways, normal & mile stone where mile stone snapshot releases could include all the info a formal release would include. - The ability to release snapshot still exists under the latest plugins - what's now gone missing is the ability to release everything that would be generated during a formal release i.e javadoc, site info, scm branch tagging etc. Even if a snapshot is cleaned out I think it would be very rare occasions where this would become a problem - the scm branch could in such case be used to rebuild the lost snapshot release. I think our bottom line is that we only want to see properly tested and sane releases in our "prod state" releases repo - any such release have been formally requested and approved by our Change Management process - snapshots is managed by individual developers and do not go through a sign off process. The way we integrated Archiva, project site info and Subversion works really well - this latest issue of not being able to build full snapshot releases would in effect force us to change our current process - either by banning these sort of mile stones or force developers to 1. manually branch tag the source, 2. build a local site 3. push the locally built site info out to our project web site 4. push out the snapshot to archivas snapshot repo There's a lot that can (and honestly will) go wrong here - the earlier version of the plugin took care of most of this (only issue being that a developer may overwrite the release and scm version at the prompt with wrong info) > What you are looking for is "staging": a concept where you release your > artifacts to the QA-repository. If they accept it, they push it to the > next repository, ... until it is pushed to the company-repository, ready > to be used by everyone. I will look into this - seem like a sensible way to go about things Thanks for the advice given by all cheers ----- good @ being sucked @ -- View this message in context: http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789950.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
