You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Dennis Lundberg <de...@apache.org> on 2015/02/21 23:05:37 UTC
[DISCUSS] To SemVer or not to SemVer, that is the question
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/
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Tibor Digana <ti...@apache.org>.
This is also my problem with release plugin.
I am missing version schema in <configuration />.
I guess BashShell code or some other generic approach because there might be
a lot of rules the users may require.
--
View this message in context: http://maven.40175.n5.nabble.com/DISCUSS-To-SemVer-or-not-to-SemVer-that-is-the-question-tp5827084p5827122.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Feb 22, 2015 at 7:43 AM, Lennart Jörelid
<le...@gmail.com> wrote:
> Well ... actually, Benson, the project I'm thinking of had 398 maven
> projects within one deliverable.
> Roughly divide by 3 to get the number of APIs there - implying the number
> of API projects are at the 130+ level.
>
> However - just throw into the mix that you are creating a 100% uptime
> project where parts must be upgradeable at all times.
> That implies something like OSGi - which means that all Implementation, SPI
> and Model projects must *also* adhere to semver.
> Otherwise you cannot simply replace an implementation with a bugfixed one
> while the app is running....
>
> ... so I would claim that there are scenarios where semver is required for
> all the project parts.
> And that the release plugin in its current state is close to unuseable in
> catering for these scenarios.
Yow! ok, point taken.
>
>
> 2015-02-22 12:44 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>
>> On Sun, Feb 22, 2015 at 6:26 AM, Lennart Jörelid
>> <le...@gmail.com> wrote:
>> > Actually, Dennis, I would argue that your problem is the smaller one of
>> the
>> > two main problems with the release plugin.
>> >
>> > The bigger problem is that the release plugin requires too much manual
>> > fiddling to apply in a big maven reactor. For example; given a reactor
>> with
>> > 250+ maven projects you want to make a new release since 74 of these 250+
>> > projects now contain changes following 4 refactorings. The question now
>> is
>> > not one of which semantic versioning principle I'm applying but simply
>> one
>> > of practicality:
>> >
>> > Which of the 74 projects should now receive a major, minor or micro
>> version
>> > upgrade?
>>
>> I would be somewhat in awe of a project that included 74 components
>> that all (or even most) published an API that needed SemVer. My point
>> here is commentary on yours, not an argument. In my experiment,
>> typically a multi-module monster has one 'api', and then a complex
>> internal structure. To the outside world, SemVer applies to the API,
>> not to all the insides. Or, it applies to the union. If the pieces are
>> so independent that your scenario applies, I would wonder if a
>> multi-module structure is really appropriate.
>>
>>
>> > As deliverables scale, the burden of using a proper versioning scheme is
>> > simply that there is no tooling support in figuring out if a change in
>> > project X should yield a major, minor or micro version bump - and doing
>> > this manually is simply not a scalable task at all.
>> >
>> > The release plugin seems fine to use when it comes to smaller projects
>> such
>> > as most of the maven plugins, but it has distinct usability problems for
>> > bigger reactors. Release managers in most of my later projects simply
>> > decided that the only sensible solution was to (re-)release all projects
>> in
>> > the reactor with new versions. This implies that most of the maven
>> > component projects misuse semver, but that the release process works....
>> at
>> > all.
>> >
>> > I believe that we need a plugin which could calculate a suggested version
>> > for a project given the last release's binary API and changes since the
>> > last release (in the style of clirr + something else). Such a plugin
>> would
>> > also be really useful in a continuous delivery scenario where semver is
>> > needed but largely ignored due to technical difficulties in calculating
>> > version numbers.
>> >
>> >
>> >
>> > 2015-02-21 23:05 GMT+01:00 Dennis Lundberg <de...@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/
>> >>
>> >> --
>> >> Dennis Lundberg
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> >
>> > --
>> > +==============================+
>> > | Bästa hälsningar,
>> > | [sw. "Best regards"]
>> > |
>> > | Lennart Jörelid
>> > | EAI Architect & Integrator
>> > |
>> > | jGuru Europe AB
>> > | Mölnlycke - Kista
>> > |
>> > | Email: lj@jguru.se
>> > | URL: www.jguru.se
>> > | Phone
>> > | (skype): jgurueurope
>> > | (intl): +46 708 507 603
>> > | (domestic): 0708 - 507 603
>> > +==============================+
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
>
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Lennart Jörelid <le...@gmail.com>.
Well ... actually, Benson, the project I'm thinking of had 398 maven
projects within one deliverable.
Roughly divide by 3 to get the number of APIs there - implying the number
of API projects are at the 130+ level.
However - just throw into the mix that you are creating a 100% uptime
project where parts must be upgradeable at all times.
That implies something like OSGi - which means that all Implementation, SPI
and Model projects must *also* adhere to semver.
Otherwise you cannot simply replace an implementation with a bugfixed one
while the app is running....
... so I would claim that there are scenarios where semver is required for
all the project parts.
And that the release plugin in its current state is close to unuseable in
catering for these scenarios.
2015-02-22 12:44 GMT+01:00 Benson Margulies <bi...@gmail.com>:
> On Sun, Feb 22, 2015 at 6:26 AM, Lennart Jörelid
> <le...@gmail.com> wrote:
> > Actually, Dennis, I would argue that your problem is the smaller one of
> the
> > two main problems with the release plugin.
> >
> > The bigger problem is that the release plugin requires too much manual
> > fiddling to apply in a big maven reactor. For example; given a reactor
> with
> > 250+ maven projects you want to make a new release since 74 of these 250+
> > projects now contain changes following 4 refactorings. The question now
> is
> > not one of which semantic versioning principle I'm applying but simply
> one
> > of practicality:
> >
> > Which of the 74 projects should now receive a major, minor or micro
> version
> > upgrade?
>
> I would be somewhat in awe of a project that included 74 components
> that all (or even most) published an API that needed SemVer. My point
> here is commentary on yours, not an argument. In my experiment,
> typically a multi-module monster has one 'api', and then a complex
> internal structure. To the outside world, SemVer applies to the API,
> not to all the insides. Or, it applies to the union. If the pieces are
> so independent that your scenario applies, I would wonder if a
> multi-module structure is really appropriate.
>
>
> > As deliverables scale, the burden of using a proper versioning scheme is
> > simply that there is no tooling support in figuring out if a change in
> > project X should yield a major, minor or micro version bump - and doing
> > this manually is simply not a scalable task at all.
> >
> > The release plugin seems fine to use when it comes to smaller projects
> such
> > as most of the maven plugins, but it has distinct usability problems for
> > bigger reactors. Release managers in most of my later projects simply
> > decided that the only sensible solution was to (re-)release all projects
> in
> > the reactor with new versions. This implies that most of the maven
> > component projects misuse semver, but that the release process works....
> at
> > all.
> >
> > I believe that we need a plugin which could calculate a suggested version
> > for a project given the last release's binary API and changes since the
> > last release (in the style of clirr + something else). Such a plugin
> would
> > also be really useful in a continuous delivery scenario where semver is
> > needed but largely ignored due to technical difficulties in calculating
> > version numbers.
> >
> >
> >
> > 2015-02-21 23:05 GMT+01:00 Dennis Lundberg <de...@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/
> >>
> >> --
> >> Dennis Lundberg
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> >
> > --
> > +==============================+
> > | Bästa hälsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart Jörelid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | Mölnlycke - Kista
> > |
> > | Email: lj@jguru.se
> > | URL: www.jguru.se
> > | Phone
> > | (skype): jgurueurope
> > | (intl): +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Feb 22, 2015 at 6:26 AM, Lennart Jörelid
<le...@gmail.com> wrote:
> Actually, Dennis, I would argue that your problem is the smaller one of the
> two main problems with the release plugin.
>
> The bigger problem is that the release plugin requires too much manual
> fiddling to apply in a big maven reactor. For example; given a reactor with
> 250+ maven projects you want to make a new release since 74 of these 250+
> projects now contain changes following 4 refactorings. The question now is
> not one of which semantic versioning principle I'm applying but simply one
> of practicality:
>
> Which of the 74 projects should now receive a major, minor or micro version
> upgrade?
I would be somewhat in awe of a project that included 74 components
that all (or even most) published an API that needed SemVer. My point
here is commentary on yours, not an argument. In my experiment,
typically a multi-module monster has one 'api', and then a complex
internal structure. To the outside world, SemVer applies to the API,
not to all the insides. Or, it applies to the union. If the pieces are
so independent that your scenario applies, I would wonder if a
multi-module structure is really appropriate.
> As deliverables scale, the burden of using a proper versioning scheme is
> simply that there is no tooling support in figuring out if a change in
> project X should yield a major, minor or micro version bump - and doing
> this manually is simply not a scalable task at all.
>
> The release plugin seems fine to use when it comes to smaller projects such
> as most of the maven plugins, but it has distinct usability problems for
> bigger reactors. Release managers in most of my later projects simply
> decided that the only sensible solution was to (re-)release all projects in
> the reactor with new versions. This implies that most of the maven
> component projects misuse semver, but that the release process works.... at
> all.
>
> I believe that we need a plugin which could calculate a suggested version
> for a project given the last release's binary API and changes since the
> last release (in the style of clirr + something else). Such a plugin would
> also be really useful in a continuous delivery scenario where semver is
> needed but largely ignored due to technical difficulties in calculating
> version numbers.
>
>
>
> 2015-02-21 23:05 GMT+01:00 Dennis Lundberg <de...@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/
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
>
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Lennart Jörelid <le...@gmail.com>.
Actually, Dennis, I would argue that your problem is the smaller one of the
two main problems with the release plugin.
The bigger problem is that the release plugin requires too much manual
fiddling to apply in a big maven reactor. For example; given a reactor with
250+ maven projects you want to make a new release since 74 of these 250+
projects now contain changes following 4 refactorings. The question now is
not one of which semantic versioning principle I'm applying but simply one
of practicality:
Which of the 74 projects should now receive a major, minor or micro version
upgrade?
As deliverables scale, the burden of using a proper versioning scheme is
simply that there is no tooling support in figuring out if a change in
project X should yield a major, minor or micro version bump - and doing
this manually is simply not a scalable task at all.
The release plugin seems fine to use when it comes to smaller projects such
as most of the maven plugins, but it has distinct usability problems for
bigger reactors. Release managers in most of my later projects simply
decided that the only sensible solution was to (re-)release all projects in
the reactor with new versions. This implies that most of the maven
component projects misuse semver, but that the release process works.... at
all.
I believe that we need a plugin which could calculate a suggested version
for a project given the last release's binary API and changes since the
last release (in the style of clirr + something else). Such a plugin would
also be really useful in a continuous delivery scenario where semver is
needed but largely ignored due to technical difficulties in calculating
version numbers.
2015-02-21 23:05 GMT+01:00 Dennis Lundberg <de...@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/
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Robert Scholte <rf...@apache.org>.
Hi Lennart,
There's a github mirror for all Apache projects:
https://github.com/apache/maven-release
thanks,
Robert
Op Sun, 22 Feb 2015 16:03:51 +0100 schreef Lennart Jörelid
<le...@gmail.com>:
> 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 <rf...@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 <
>> dennisl@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Lennart Jörelid <le...@gmail.com>.
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 <rf...@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 <
> dennisl@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Robert Scholte <rf...@apache.org>.
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
<de...@apache.org>:
> Thanks Robert,
>
> I'll have a look at it.
>
> On Sun, Feb 22, 2015 at 1:00 PM, Robert Scholte <rf...@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
>> <de...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Stephen Connolly <st...@gmail.com>.
On 23 February 2015 at 13:45, Lennart Jörelid <le...@gmail.com>
wrote:
> Hello all again,
>
> This is exactly my experience with large reactors; while semver would be
> the desired way to go it is impractical bordering on impossible to combine
> semver for a large number of projects. (In fact, it boils down to manually
> correctly managing all versions within a release.properties file, which is
> practially impossible for a large reactor).
>
> Thus, the only realistic option (due to the way that the release plugin
> currently
> works) is to release all the subprojects within the reactor as a whole.
> This is
> basically saying that we sacrifice semver to acquire smoother releases. We
> also sacrifice upgradeability for bugfixes in implementation projects to
> acquire
> a workable release.
>
> Conclusion: As the number of projects in a reactor grows, the maven tools
> (in particular the maven-release-plugin in its current state) are unsuitabe
> for combining an efficient release process and semver.
>
Well the question you really need to ask is different then isn't it?
First we need to consider what a release root is.
To me a release root encapsulates all the modules that are captured in a
single tag and released as a unit (never mind atomic or non-atomic deploys,
we are dealing with more ideal processes)
So when we use a release root, ideally, everything in that release root
should have the exact same version number. If you are to have different
version numbers of modules within that release root then there must have
been one of two things driving that:
1. Historically, at least one module existed independent from this release
root and was refactored into the release root. For consistency, it's
version number was not reset during the refactor
2. We may need to release some of the modules independently from the rest
of the release root... this really speaks to these modules being
incorrectly part of the release root.
The first case can be viewed as a transient problem, eventually you will
cut a major version bump to get to alignment.
The second case really speaks to a poorly formed release root. Those
modules should not actually be part of the release root.
Why is this important? Because the principle of the release root says that
everything should have the same version within the release root. Thus if
you are following semver, the semver scope is *everything in the release
root* not each individual module. So if _one_ of your modules in the
release root has a backwards breaking compatibility change, then _all_
modules are subjected to a major version bump... if you don't like that,
then you either don't like semver or you didn't construct your release root
correctly.
I can feel people itching to say that I am wrong on the above... so let me
ask you this...
Do you version the packages _within each jar_? Does each package have a
package-info.java with a doc comment saying "package version x.y.z"?
Just because you package up all three packages `com.acme.foo.api`,
`com.acme.foo.impl.bar` and `com.acme.foo.impl.manchu` into the single jar
file does not mean that I consume all three of them. I might be just
unpacking `com.acme.foo.api` with a view to writing my own implementation,
so I do not care that your `com.acme.foo.impl.bar` has had a breaking
change.
We can go further, and ask do you version each individual class file using
semver?
These are all individual components that we choose to release as a single
unit (i.e. a jar file). Thus the version number of the composite is
determined by the worst change of any single individual component.
We could look at that jar file and say... you know what, we have users that
just want the API. Let's put the API into a different jar from the IMPL.
Now we have two jar files, so we can have two version numbers... but we
still always release them in tandem, so they have the same version number...
Some time later we have a bug that needs fixing in the IMPL. The QA process
for testing a new release of the API is quite involved so nobody wants a
new version of the API when nothing has changed... that is a smell that the
API and IMPL need to be released independently, so they need to be in
separate release roots...
And now we hit the main issue. *Currently* the maven-release-plugin only
works on a single release root.
I have a ruby script that reads the root pom file and identifies all
release roots, determines which have unreleased changes, determines the
dependencies between release roots, and then releases each one in turn
(using the maven-release-plugin) updating dependency versions as it goes,
until there are no release roots with unreleased changes... (my script also
has a special flag I call `--yolo` where it doesn't ask questions and runs
the releases with `-B`)
What I want to do is port that logic into the release plugin, which would
effectively enable people to have their release roots less big and more
closely match the needs of each module.
A final point is that very large reactors probably are ill suited to
independent module versioning anyway. You end up with lots of different
components and people basically end up having dependencies for each use
case if they have a need for cross-cutting dependency selection... and if
you don't have such a need then you typically end up depending on
everything anyway.
So you have the foo-db-access and foo-comms "dependency-set" plugins which
pull in the required modules in all their multi-version glory via
transitive dependency resolution... and how do we version those
"dependency-set" plugins? If using semver, well they need to follow the
worst version change of their dependencies... foo-logging got a major
version bump... so foo-db-access and foo-comms both need a version bump...
next release foo-utils gets a major version bump, so again foo-db-access
and foo-comms need a major version bump... etc. Very soon all your regular
modules have had one version bump (you are practicing CD) and your
"dependency-set" plugins are on version 48.0.0 and 56.0.0 respectively
(because say there are 47 and 55 dependencies pulled in to each
respectively)
Now there is nothing really wrong with that... except that when it comes to
tracing user problems you need a major matrix to help you decide if there
is something wrong with the system (perhaps they have got foo-widget 3.0.4
and that was never tested with foo-gasket 5.0.3 because they were not
released as a unit)... plus the users don't care about the foo-widget and
foo-gasket version numbers because you have given them the nice handy
foo-comms "dependency-set" that is all they bother tracking... and so you
realise:
* either the release root is too big;
* I should just quit messing around and give them all the same version
number anyway.
So my conclusion is that we need not bring maven or the maven release
plugin into this discussion at all.
For releasing many individual things always as one atomic transaction,
semver is best applied to everything in the transaction as a whole. Semver
is ill-suited to versioning the individual components *if* you will always
release them atomically as a whole.
Maven, as it always does, lets you ignore this but punishes you with a
world of pain if you deviate from the best practice of giving everything in
a release root the same version number
;-)
>
>
> 2015-02-23 11:43 GMT+01:00 Martijn Dashorst <ma...@gmail.com>:
>
> > On Sun, Feb 22, 2015 at 10:42 PM, Fred Cooke <fr...@gmail.com>
> wrote:
> > > I'd also love to hear that no one is trying to release 200 artifacts
> in a
> > > single reactor.
> >
> > At Wicket Stuff (https://github.com/wicketstuff) we do just that. It
> > is a pain, but
> > it is quite a lot less pain than trying to release each project by
> itself.
> >
> > > That makes no sense at all, to me. The chances are on a big
> > > corporate project you've only changed <25% of them per top level
> release
> > > anyway. So to run a top level MVN release against the entire tree would
> > > produce 75% duplicate (by code, not number) artifacts. Or did I
> > > misunderstand?
> >
> > You understand correctly, but in Wicket Stuff's particular case we assume
> > that
> > while not everything was modified, it is a much bigger benefit of having
> > all
> > version of all sub modules align, such that we can ensure that one
> > particular
> > version of Wicket works with one particular version of any Wicket Stuff
> > project.
> >
> > For a release manager it is actually hard to figure out which projects
> > should
> > be released, releases of submodules linger long etc. The benefits for the
> > community with regular, full releases are tremendous. No more trying to
> > figure
> > out which versions will work with your version of Wicket.
> >
> > Martijn
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
>
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Lennart Jörelid <le...@gmail.com>.
Hello all again,
This is exactly my experience with large reactors; while semver would be
the desired way to go it is impractical bordering on impossible to combine
semver for a large number of projects. (In fact, it boils down to manually
correctly managing all versions within a release.properties file, which is
practially impossible for a large reactor).
Thus, the only realistic option (due to the way that the release plugin
currently
works) is to release all the subprojects within the reactor as a whole.
This is
basically saying that we sacrifice semver to acquire smoother releases. We
also sacrifice upgradeability for bugfixes in implementation projects to
acquire
a workable release.
Conclusion: As the number of projects in a reactor grows, the maven tools
(in particular the maven-release-plugin in its current state) are unsuitabe
for combining an efficient release process and semver.
2015-02-23 11:43 GMT+01:00 Martijn Dashorst <ma...@gmail.com>:
> On Sun, Feb 22, 2015 at 10:42 PM, Fred Cooke <fr...@gmail.com> wrote:
> > I'd also love to hear that no one is trying to release 200 artifacts in a
> > single reactor.
>
> At Wicket Stuff (https://github.com/wicketstuff) we do just that. It
> is a pain, but
> it is quite a lot less pain than trying to release each project by itself.
>
> > That makes no sense at all, to me. The chances are on a big
> > corporate project you've only changed <25% of them per top level release
> > anyway. So to run a top level MVN release against the entire tree would
> > produce 75% duplicate (by code, not number) artifacts. Or did I
> > misunderstand?
>
> You understand correctly, but in Wicket Stuff's particular case we assume
> that
> while not everything was modified, it is a much bigger benefit of having
> all
> version of all sub modules align, such that we can ensure that one
> particular
> version of Wicket works with one particular version of any Wicket Stuff
> project.
>
> For a release manager it is actually hard to figure out which projects
> should
> be released, releases of submodules linger long etc. The benefits for the
> community with regular, full releases are tremendous. No more trying to
> figure
> out which versions will work with your version of Wicket.
>
> Martijn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Martijn Dashorst <ma...@gmail.com>.
On Sun, Feb 22, 2015 at 10:42 PM, Fred Cooke <fr...@gmail.com> wrote:
> I'd also love to hear that no one is trying to release 200 artifacts in a
> single reactor.
At Wicket Stuff (https://github.com/wicketstuff) we do just that. It
is a pain, but
it is quite a lot less pain than trying to release each project by itself.
> That makes no sense at all, to me. The chances are on a big
> corporate project you've only changed <25% of them per top level release
> anyway. So to run a top level MVN release against the entire tree would
> produce 75% duplicate (by code, not number) artifacts. Or did I
> misunderstand?
You understand correctly, but in Wicket Stuff's particular case we assume that
while not everything was modified, it is a much bigger benefit of having all
version of all sub modules align, such that we can ensure that one particular
version of Wicket works with one particular version of any Wicket Stuff project.
For a release manager it is actually hard to figure out which projects should
be released, releases of submodules linger long etc. The benefits for the
community with regular, full releases are tremendous. No more trying to figure
out which versions will work with your version of Wicket.
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Fred Cooke <fr...@gmail.com>.
That makes some sense, but a more generic big project where the life cycle
of each component is distinct and meaingfully distinct, it does not. I can
think of another good case, albeit with a much lower number of moving
parts: Parent sets. It's nice to have only one current version number to
remember when you're poking around your POM and spot the parent tags. In
this case I'd rather have duplicate releases because as a set, they work
together well, or so it should be.
Strict adherence to SemVer is a bit of a fail anyway, provided your
versions have semantic meaning that is well defined within their context,
you're doing well. For example, your long lived release branches.
On Mon, Feb 23, 2015 at 5:09 PM, Chris Graham <ch...@gmail.com> wrote:
> On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke <fr...@gmail.com> wrote:
>
> >
> > I'd also love to hear that no one is trying to release 200 artifacts in a
> > single reactor. That makes no sense at all, to me. The chances are on a
> big
> > corporate project you've only changed <25% of them per top level release
> > anyway. So to run a top level MVN release against the entire tree would
> > produce 75% duplicate (by code, not number) artifacts. Or did I
> > misunderstand?
> >
>
> From a pragmatic, not a SemVer point of view, it makes a lot of sense. I
> can think of some Message Broker projects that I did, with a few hundred
> message sets. You're right, in that the % change is minimal. The issue is
> that it's rarely the same modules that change. And in that sense, setting
> up the SCM tagging would be a nightmare.
>
> So, what I've done is to set up a monolithic build, where I rebuild
> everything everytime, and release everything time. So it's not SemVer, but
> it works. I can verify the SCM provenance of the code with a single tag.
> The only thing that defines a vesion, is that it's different, in some way,
> to another another version.
>
> In message brokers case, it drastically simplifies the deployment options,
> it's simple as everything gets deployed each and every time. Automating the
> deployment of a single message set across any given number of bar files
> into whatever execution groups require it would be next to impossible (and
> not worth the effort in doing so).
>
> I used long life release branches (a release of X.Y lives in it's own
> branch, in some cases up to 18 months), with many releases of
> X.Y.Z-SNAPSHOT on the branch. The last project used Oracle CC&B, and we
> have 5 concurrent release branches. SemVer in that instance is not doable.
>
> So yes, the same code will be tagged multiple times, with different
> versions with no real changes to the module. And that is fine. You've also
> got to remember that I set the maven builds up underneath the devs, so that
> they were not aware of it, other than this strange looking pom.xml that
> suddenly appeared in their projects :)
>
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Chris Graham <ch...@gmail.com>.
On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke <fr...@gmail.com> wrote:
>
> I'd also love to hear that no one is trying to release 200 artifacts in a
> single reactor. That makes no sense at all, to me. The chances are on a big
> corporate project you've only changed <25% of them per top level release
> anyway. So to run a top level MVN release against the entire tree would
> produce 75% duplicate (by code, not number) artifacts. Or did I
> misunderstand?
>
>From a pragmatic, not a SemVer point of view, it makes a lot of sense. I
can think of some Message Broker projects that I did, with a few hundred
message sets. You're right, in that the % change is minimal. The issue is
that it's rarely the same modules that change. And in that sense, setting
up the SCM tagging would be a nightmare.
So, what I've done is to set up a monolithic build, where I rebuild
everything everytime, and release everything time. So it's not SemVer, but
it works. I can verify the SCM provenance of the code with a single tag.
The only thing that defines a vesion, is that it's different, in some way,
to another another version.
In message brokers case, it drastically simplifies the deployment options,
it's simple as everything gets deployed each and every time. Automating the
deployment of a single message set across any given number of bar files
into whatever execution groups require it would be next to impossible (and
not worth the effort in doing so).
I used long life release branches (a release of X.Y lives in it's own
branch, in some cases up to 18 months), with many releases of
X.Y.Z-SNAPSHOT on the branch. The last project used Oracle CC&B, and we
have 5 concurrent release branches. SemVer in that instance is not doable.
So yes, the same code will be tagged multiple times, with different
versions with no real changes to the module. And that is fine. You've also
got to remember that I set the maven builds up underneath the devs, so that
they were not aware of it, other than this strange looking pom.xml that
suddenly appeared in their projects :)
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Fred Cooke <fr...@gmail.com>.
It's worth pointing out that if you just run the two part version in the
first place you are doing the same thing. IE, internally maven's versions
are always x.y.z even if you only specify x.y thus if you have 2.6 and
you're doing SemVer (2+, 1 sucked), then it'll behave correctly. Add the
patches if/when you need them like usual.
I'd also love to hear that no one is trying to release 200 artifacts in a
single reactor. That makes no sense at all, to me. The chances are on a big
corporate project you've only changed <25% of them per top level release
anyway. So to run a top level MVN release against the entire tree would
produce 75% duplicate (by code, not number) artifacts. Or did I
misunderstand?
On Mon, Feb 23, 2015 at 9:55 AM, Dennis Lundberg <de...@apache.org> wrote:
> Thanks Robert,
>
> I'll have a look at it.
>
> On Sun, Feb 22, 2015 at 1:00 PM, Robert Scholte <rf...@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
> > <de...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Dennis Lundberg <de...@apache.org>.
Thanks Robert,
I'll have a look at it.
On Sun, Feb 22, 2015 at 1:00 PM, Robert Scholte <rf...@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
> <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Robert Scholte <rf...@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
<de...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] To SemVer or not to SemVer, that is the question
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
I know its not your problem domain, but I wanted to point out that the
OSGi bnd-tool can do exactly that. It can even differentiate for
interface providers and consumers.
http://www.aqute.biz/Bnd/Versioning
However the question is, if it really works all automatic if you are
not strictly developing with that in mind (and if you do it it is still
in the interest of your users).
Gruss
Bernd
Am Sat, 21 Feb 2015 23:05:37
+0100 schrieb Dennis Lundberg <de...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org