Hello Robert, I figured I'd take a look at this to possibly throw in some ideas/experiences from earlier projects. Is there a Git mirror available?
2015-02-22 13:00 GMT+01:00 Robert Scholte <rfscho...@apache.org>: > Hi Dennis, > > I've already started to extract some parts of the maven-release-manager to > an API. > The project has now 4 modules[1], whereas the maven-release-apis[2] should > be interesting. > I've started with a VersionPolicy interface, Simone already started on his > own implementation of OddEven Policy[3] > The current version already works with this API and the default > implementation, so there's only one more step to take: make it settable by > plugin configuration. > So you could work on the SemVer policy based on this API. If this confirms > that the API for version policy is complete, we can expose it. > > thanks, > Robert > > [1] http://maven.apache.org/maven-release/ > [2] http://maven.apache.org/maven-release/maven-release-api/ > apidocs/index.html > [3] http://maven.apache.org/maven-release/maven-release- > policies/maven-release-oddeven-policy/index.html > > > Op Sat, 21 Feb 2015 23:05:37 +0100 schreef Dennis Lundberg < > denn...@apache.org>: > > > Hi, >> >> Although I strongly feel that SemVer [1] is the way to go when it >> comes to versioning, I still haven't started using it though. That got >> me thinking about why that is the case. I've come to the conclusion >> that I'm lazy :) >> >> It all comes down to tooling. Being accustomed to, and spoiled by, >> using the Release Plugin, I don't want to do anything manually any >> more. That includes as simple a thing as changing the "next version" >> (or developmentVersion) manually during the interactive command line >> session when using the Release Plugin. I want it to be the guessed >> correctly for me. Let me outline an example to show you what I mean. >> The vast majority of releases I make, both here and at my day job, are >> minor releases. So I want the Release Plugin to work for me, and not >> against me. >> >> >> Not using SemVer >> >> 1.0-SNAPSHOT --> 1.0 --> 1.1-SNAPSHOT >> >> No problems here, the Release Plugin will correctly guess that >> 1.1-SNAPSHOT is the next version that I want to use. Just hit <enter> >> a couple of times during the release process. >> >> >> Using SemVer >> >> 1.0.0-SNAPSHOT --> 1.0.0 --> 1.0.1-SNAPSHOT >> >> This is not what I want. The Release Plugin will guess that the next >> version should be 1.0.1-SNAPSHOT. To change it I have to type in the >> value that I want on the command line. I'm too lazy for that. Instead >> I want the Release Plugin to do this: >> >> 1.0.0-SNAPSHOT --> 1.0.0 --> 1.1.0-SNAPSHOT >> >> >> How can we solve this? The solution that I have come up with is a new >> parameter for release:prepare tentatively called "versionIncrement" >> that can take the values "major", "minor" and "patch", with "patch" >> being the default value for backwards compatibility. >> >> In my use case above I would simply set versionIncrement=minor and the >> Release Plugin would then do things my way. >> >> What are your thoughts on this? >> >> I would like for us to start using SemVer for all releases in the >> Maven project, not just in core. What do you think? >> >> >> [1] http://semver.org/ >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
