Here is the practice I am adopting now: Whenever the project is open for change, use SNAPSHOT version.
Change the version to a concrete version number when you decide to perform a release. Do your release branching and tagging etc, and then immediate change the POM version back to SNAPSHOT. i.e. whenever a project source is subject to change, use SNAPSHOT as version in POM -- Best Regards, AdRiAN ShUM -----Original Message----- From: Eric Rotick [mailto:pc.gree...@gmail.com] Sent: Tuesday, June 15, 2010 7:22 PM To: users@maven.apache.org Subject: Advice on version control This might be more to do with SCM than Maven but as Maven seems to have the handle on most things I thought I'd ask this list first. It is clear that the version contained in the pom is vitally important and the process by which a version or revision number is incremented is clear. Unfortunately, someone made a mistake of making a significant change to some source and re-released the jars without changing the version. The result was that the client application would not talk to the server in certain conditions. Basically, given our current procedures, this was a problem waiting to happen. Although it is clear what needs to happen it eludes us how this is enforced. It seems that we need the ability to write snapshots any number of times but non snapshots can only be written once and then no more. Hmm, I've just thought, maybe this is what the likes of Nexus and Artifactory would do, but as you've probably guessed we don't use anything like this. Could anyone offer advice or practices to stop this happening again. Thanks. This email is confidential. If you are not the intended recipient, please delete it from your system and notify the sender immediately. Any unauthorized use, disclosure, dissemination or copying of this email is prohibited. Taifook Securities Group, its group companies and their content providers ("Parties") shall not be responsible for the accuracy or completeness of this email or its attachment, if any, which could contain virus, be corrupted, destroyed, incomplete, intercepted, lost or arrive late. The Parties do not accept liability for any damage caused by this email. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
