Project Versioning and Release - Best Practice

• A new project starts usually as version 1.0.0.0-SNAPSHOT. Three number versions (1.0.0) are also used but, for example, ServiceMix OSGi server requires three dots.
• A new feature/fix is frequently developed on the trunk and committed there when ready for release.
• Release. It is usually done on the trunk (does it have to be? what if someone commits changes in the middle of a release?). It is all done by maven release plugin, (more datails here). Is done in two steps: mvn release:prepare i mvn release:perform. What maven does during a release:
• up the version by 1 (often on the last numbered position: 1.0.0.1)
• build, maven-release and deploy to organization's repository if any
• tag it in SCM
• up the version number on the trunk (it will become 1.0.0.1-SNAPSHOT)

Notes:

• On the trunk, we have always -SNAPSHOT versions
• Each release has a tag
• If the maven release plugin fails, it usually leaves the pom.xml messed up on the trunk.  Make sure to fix the version and scm tags. 
• Alternatively,  a new feature/bug fix can be developed on a branch.  In this case, the branch needs to be merged to the trunk, when feature/bug fix is ready. I guess, this merge should happen before the release.
• In multi-module projects,  if you want to give the same new version to all modules, add set the option autoVersionSubmodules to true (in parent pom?  where?). Otherwise, you'll be asked for the new version for each module.