Hi Christian, That's ok with me, but I would like to explain why I personally prefer to use the SNAPSHOT qualifier. Maven has special handling [1] for SNAPSHOT versions (specifically with this suffix) that allows users to have projects that automatically download bleeding-edge builds from the snapshots repo (and this is something I'm interested in using). Maven automatically expands the "-SNAPSHOT" suffix into a date-time-buildNumber string (see [2] for example), which provides for reproducibility should we have users that download directly from the SNAPSHOT repo (assuming the JAR itself does not already have this info in its manifest metadata). Also, I think SNAPSHOT versioning is an easy way to tell that the code you're looking at is under active development and is not actually of a release (especially if you're sharing an exported tarball with someone). In addition, I like to use the maven-release-plugin (which requires the SNAPSHOT suffix) because it handles the versioning, tagging, and deployment for you in a single command. I've had no problems using it for releasing my other projects, and it significantly simplifies the release process for me and allows for consistency (before the plugin, I've often tagged my code with typos in the label; or I would forget to bump my development version). I now just enter: mvn release:clean release:prepare release:perform (or as individual steps if necessary) All that said, I'm perfectly fine with conforming to what's comfortable with other developers on the team. Unless somebody else speaks up now, I can live without SNAPSHOT versioning. Also, sorry to all for the notification noise from the recent check-ins. I was actually experimenting in a fork, not realizing that I was pushing to the original project. I've since removed those check-ins (as you've probably already noticed). -Tony [1] http://docs.codehaus.org/pages/viewpage.action?pageId=22585 Note: The link above is rather old, but I believe it still applies to the current versions of Maven. [2] https://oss.sonatype.org/content/repositories/snapshots/com/github/tony19/lo... On Thu, Dec 20, 2012 at 2:05 AM, Christian Trutz <christian.trutz@belaso.de>wrote:
Hi Tony,
I propose to use following workflow to version logback-contrib:
1) we don't use SNAPSHOT 2) if a version is "in work", it gets the version of the following next release 3) if a release is ready, we tag this version in GIT
For example:
- Version v_0.1.1 is ready: git tag -a v_0.1.1 - In pom.xml we have version 0.1.2 - many development iterations - Version v_0.1.2 is ready: git tag -a v_0.1.2 ...
OK?
Christian
2012/12/20 Tony Trinh <tony19@gmail.com>
Branch: refs/heads/master Home: https://github.com/qos-ch/logback-contrib Commit: cdc7faa03d32b37da39e64ba8a10d8a2359d256b
https://github.com/qos-ch/logback-contrib/commit/cdc7faa03d32b37da39e64ba8a1... Author: Tony Trinh <tony19@gmail.com> Date: 2012-12-19 (Wed, 19 Dec 2012)
Changed paths: M pom.xml
Log Message: ----------- Add SNAPSHOT label to version
Commit: 74dca95fb9432f96dae2ef4707ebc44d8885cc81
https://github.com/qos-ch/logback-contrib/commit/74dca95fb9432f96dae2ef4707e... Author: Tony Trinh <tony19@gmail.com> Date: 2012-12-19 (Wed, 19 Dec 2012)
Log Message: ----------- Merge branch 'master' into fixbr
Commit: 082e705d09b557ac69eb77dfc7e6d6f59b31a4ed
https://github.com/qos-ch/logback-contrib/commit/082e705d09b557ac69eb77dfc7e... Author: Tony Trinh <tony19@gmail.com> Date: 2012-12-19 (Wed, 19 Dec 2012)
Changed paths: M eclipse/pom.xml M jackson/pom.xml M json/classic/pom.xml M json/core/pom.xml M json/pom.xml M mongodb/access/pom.xml M mongodb/classic/pom.xml M mongodb/core/pom.xml M mongodb/pom.xml M pom.xml
Log Message: ----------- [maven-release-plugin] prepare release v_0.1.2
Compare: https://github.com/qos-ch/logback-contrib/compare/262b20f15678...082e705d09b...
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev