It should be as easy as http://svn.apache.org/r1669762
Again: custom VersionPolicies aren't exposed yet by the plugin. I've added
this, so we have time to complete the API, e.g. do we have enough
information to predict the next version? In the end it is just a matter of
writing proper unittests.
Thanks,
Robert
Op Sun, 22 Feb 2015 21:55:43 +0100 schreef Dennis Lundberg
<denn...@apache.org>:
Thanks Robert,
I'll have a look at it.
On Sun, Feb 22, 2015 at 1:00 PM, Robert Scholte <rfscho...@apache.org>
wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
