You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2012/12/12 08:54:12 UTC
[VOTE] adopt semantic versioning
I raised this topic in a recent discussion thread, but would like to have
it formally voted on because I think it's pretty important.
The proposal is to adopt semantic versioning [1] for both Isis core and the
components. More detail below on this.
The vote will be open for 72 hours.
[ ] +1
[ ] 0
[ ] -1 ... please explain why
~~~~~
More detail on the proposal:
Version numbers are in the form x.y.z :
- x is bumped up whenever there a breaking API change
- y is bumped up whenever there is a new feature that does not break API
- z is bumped up for minor bug fixes.
This scheme would be adopted for both core and components. Version numbers
would not be kept in sync. Version ranges may not be used (*)
For example
* core 1.0.0 is released
* isis-objectstore-jdo 1.0.0 is released, dependent on core 1.0.0
* isis-viewer-wicket 1.0.0 is released, dependent on core 1.0.0
* core 1.0.1 is released. This is NOT picked up by either of the above
components.
* isis-objectstore-jdo 1.0.1 is released, dependent on core 1.0.1. This
also incorporates a number of its own bug fixes
* core 1.1.0 is released, providing a new feature
* isis-viewer-wicket 1.1.0 is released, using the new feature provided by
core 1.1.0
* isis-viewer-wicket 1.2.0 is released, offering its own new feature. It
still depends on core 1.1.0.
* isis-objectstore-jdo 1.0.2 is released. This has some bug fixes and
depends on core 1.1.0 (even though it does require the new feature
introduced in core 1.1.0)
* core 2.0.0 is released, making breaking changes to the objectstore API
* isis-objectstore-jdo 2.0.0 is released, dependent on core 2.0.0
* isis-objectstore-jdo 2.1.0 is released, providing a new feature. It
depends on core 2.0.0.
* isis-viewer-wicket 1.2.1 is released. This has some bug fixes, and also
updates to run against core 2.0.0
At the end of this sequence we have:
- core 2.0.0
- isis-objectstore-jdo 2.1.0, dependent upon core 2.0.0
- isis-wicket-viewer 1.2.1, dependent upon core 2.0.0
To avoid "jar hell" (components having conflicting dependencies of core)
our recommendation to end-users would be to configure the
maven-enforcer-plugin and its DependencyConvergence rule (good practice for
all maven projects) [2]
(*) with semantic versioning it might make sense to allow for version
ranges for the "z" and perhaps "y" components. HOWEVER, I recall that one
of the plugins we use for release - can't remember which one just now - has
a bug meaning that we cannot do this even if we wanted to.
[1] http://semver.org.
[2]
http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
Re: [VOTE] adopt semantic versioning
Posted by Jeroen van der Wal <je...@stromboli.it>.
+1
On Wed, Dec 12, 2012 at 9:05 AM, Dan Haywood
<da...@haywood-associates.co.uk>wrote:
> my own +1
>
Re: [VOTE] adopt semantic versioning
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
my own +1
Re: [VOTE] adopt semantic versioning
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
+1
On 12 Dec 2012 at 7:54, Dan Haywood wrote:
> I raised this topic in a recent discussion thread, but would like to have
> it formally voted on because I think it's pretty important.
>
> The proposal is to adopt semantic versioning [1] for both Isis core and the
> components. More detail below on this.
>
> The vote will be open for 72 hours.
>
> [ ] +1
> [ ] 0
> [ ] -1 ... please explain why
>
Re: [VOTE] adopt semantic versioning
Posted by Minto van der Sluis <mi...@xup.nl>.
+1
Op 12-12-2012 8:54, Dan Haywood schreef:
> I raised this topic in a recent discussion thread, but would like to have
> it formally voted on because I think it's pretty important.
>
> The proposal is to adopt semantic versioning [1] for both Isis core and the
> components. More detail below on this.
>
> The vote will be open for 72 hours.
>
> [ ] +1
> [ ] 0
> [ ] -1 ... please explain why
>
> ~~~~~
> More detail on the proposal:
>
> Version numbers are in the form x.y.z :
> - x is bumped up whenever there a breaking API change
> - y is bumped up whenever there is a new feature that does not break API
> - z is bumped up for minor bug fixes.
>
> This scheme would be adopted for both core and components. Version numbers
> would not be kept in sync. Version ranges may not be used (*)
>
> For example
>
> * core 1.0.0 is released
> * isis-objectstore-jdo 1.0.0 is released, dependent on core 1.0.0
> * isis-viewer-wicket 1.0.0 is released, dependent on core 1.0.0
> * core 1.0.1 is released. This is NOT picked up by either of the above
> components.
> * isis-objectstore-jdo 1.0.1 is released, dependent on core 1.0.1. This
> also incorporates a number of its own bug fixes
> * core 1.1.0 is released, providing a new feature
> * isis-viewer-wicket 1.1.0 is released, using the new feature provided by
> core 1.1.0
> * isis-viewer-wicket 1.2.0 is released, offering its own new feature. It
> still depends on core 1.1.0.
> * isis-objectstore-jdo 1.0.2 is released. This has some bug fixes and
> depends on core 1.1.0 (even though it does require the new feature
> introduced in core 1.1.0)
> * core 2.0.0 is released, making breaking changes to the objectstore API
> * isis-objectstore-jdo 2.0.0 is released, dependent on core 2.0.0
> * isis-objectstore-jdo 2.1.0 is released, providing a new feature. It
> depends on core 2.0.0.
> * isis-viewer-wicket 1.2.1 is released. This has some bug fixes, and also
> updates to run against core 2.0.0
>
> At the end of this sequence we have:
> - core 2.0.0
> - isis-objectstore-jdo 2.1.0, dependent upon core 2.0.0
> - isis-wicket-viewer 1.2.1, dependent upon core 2.0.0
>
> To avoid "jar hell" (components having conflicting dependencies of core)
> our recommendation to end-users would be to configure the
> maven-enforcer-plugin and its DependencyConvergence rule (good practice for
> all maven projects) [2]
>
>
> (*) with semantic versioning it might make sense to allow for version
> ranges for the "z" and perhaps "y" components. HOWEVER, I recall that one
> of the plugins we use for release - can't remember which one just now - has
> a bug meaning that we cannot do this even if we wanted to.
>
> [1] http://semver.org.
> [2]
> http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
[RESULT] [VOTE] adopt semantic versioning
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
This is to record that the recent vote [1] on whether to adopt semantic
versioning for Isis components was SUCCESSFUL.
PMC: +5 Dan, Jeroen, Kevin, Rob, Mark
Others: +1 Minto
No other votes were cast.
~~~
The site has been updated to document this policy [2]
[1] http://markmail.org/thread/vhivzswwtytl7f6t
[2] http://isis.apache.org/contributors/versioning-policy.html
[RESULT] [VOTE] adopt semantic versioning
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
This is to record that the recent vote [1] on whether to adopt semantic
versioning for Isis components was SUCCESSFUL.
PMC: +5 Dan, Jeroen, Kevin, Rob, Mark
Others: +1 Minto
No other votes were cast.
~~~
The site has been updated to document this policy [2]
[1] http://markmail.org/thread/vhivzswwtytl7f6t
[2] http://isis.apache.org/contributors/versioning-policy.html
Re: [VOTE] adopt semantic versioning
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
OK, closing this vote now. Result in separate post.
On 15 December 2012 16:21, Mark Struberg <st...@yahoo.de> wrote:
> +1
>
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Robert Matthews <rm...@nakedobjects.org>
> > To: dev@isis.apache.org
> > Cc:
> > Sent: Thursday, December 13, 2012 8:20 PM
> > Subject: Re: [VOTE] adopt semantic versioning
> >
> > I was always happy about the version numbering. I was concerned that the
> > restriction on ranges would be a problem, but Maven is doing it anyway -
> > I've never actually used ranges.
> >
> > +1
> >
> > PS is it worth making your release experiment available so I can try out
> > releasing a component. Or are you close enough that it will be quicker
> > (from both sides) to wait for the real release.
> >
> >
> > On 12/13/12 00:31, Dan Haywood wrote:
> >> On 13 December 2012 00:01, Robert Matthews
> > <rm...@nakedobjects.org>wrote:
> >>
> >>> However this is not a problem with Maven and it's plug-ins, I
> > specify -
> >>> very specifically - what version of a plug-in I want to use, but I can
> > use
> >>> that with version 3.0.2, 3.0.3 or 3.0.4 of Maven, it'll probably
> > even work
> >>> with version 2 as well.
> >>>
> >>> What am I missing?
> >>>
> >> In fact, in most cases you will also be able to do this in Isis... the
> >> point is that it isn't a "certified release", and so the
> > end-user is to
> >> some extent risking JAR hell. But yes, you could take the latest
> >> isis-wicket-viewer and isis-objectstore-jdo, even if they depend on
> >> different versions of core, 99% of the time it's likely to work. The
> >> version of core you'll end up running against will be determined by
> > Maven's
> >> dependency mediation rules; the developer can explicitly override by
> >> specifying the version of core in their <dependencyManagement>
> > section.
> >>
> >> The point about semantic versioning is that it will give the end-user
> >> better information to use when overriding.
> >>
> >>
> >>
> >>> Regards
> >>>
> >>> Rob
> >>>
> >>>
> >
>
Re: [VOTE] adopt semantic versioning
Posted by Mark Struberg <st...@yahoo.de>.
+1
LieGrue,
strub
----- Original Message -----
> From: Robert Matthews <rm...@nakedobjects.org>
> To: dev@isis.apache.org
> Cc:
> Sent: Thursday, December 13, 2012 8:20 PM
> Subject: Re: [VOTE] adopt semantic versioning
>
> I was always happy about the version numbering. I was concerned that the
> restriction on ranges would be a problem, but Maven is doing it anyway -
> I've never actually used ranges.
>
> +1
>
> PS is it worth making your release experiment available so I can try out
> releasing a component. Or are you close enough that it will be quicker
> (from both sides) to wait for the real release.
>
>
> On 12/13/12 00:31, Dan Haywood wrote:
>> On 13 December 2012 00:01, Robert Matthews
> <rm...@nakedobjects.org>wrote:
>>
>>> However this is not a problem with Maven and it's plug-ins, I
> specify -
>>> very specifically - what version of a plug-in I want to use, but I can
> use
>>> that with version 3.0.2, 3.0.3 or 3.0.4 of Maven, it'll probably
> even work
>>> with version 2 as well.
>>>
>>> What am I missing?
>>>
>> In fact, in most cases you will also be able to do this in Isis... the
>> point is that it isn't a "certified release", and so the
> end-user is to
>> some extent risking JAR hell. But yes, you could take the latest
>> isis-wicket-viewer and isis-objectstore-jdo, even if they depend on
>> different versions of core, 99% of the time it's likely to work. The
>> version of core you'll end up running against will be determined by
> Maven's
>> dependency mediation rules; the developer can explicitly override by
>> specifying the version of core in their <dependencyManagement>
> section.
>>
>> The point about semantic versioning is that it will give the end-user
>> better information to use when overriding.
>>
>>
>>
>>> Regards
>>>
>>> Rob
>>>
>>>
>
Re: [VOTE] adopt semantic versioning
Posted by Robert Matthews <rm...@nakedobjects.org>.
I was always happy about the version numbering. I was concerned that the
restriction on ranges would be a problem, but Maven is doing it anyway -
I've never actually used ranges.
+1
PS is it worth making your release experiment available so I can try out
releasing a component. Or are you close enough that it will be quicker
(from both sides) to wait for the real release.
On 12/13/12 00:31, Dan Haywood wrote:
> On 13 December 2012 00:01, Robert Matthews <rm...@nakedobjects.org>wrote:
>
>> However this is not a problem with Maven and it's plug-ins, I specify -
>> very specifically - what version of a plug-in I want to use, but I can use
>> that with version 3.0.2, 3.0.3 or 3.0.4 of Maven, it'll probably even work
>> with version 2 as well.
>>
>> What am I missing?
>>
> In fact, in most cases you will also be able to do this in Isis... the
> point is that it isn't a "certified release", and so the end-user is to
> some extent risking JAR hell. But yes, you could take the latest
> isis-wicket-viewer and isis-objectstore-jdo, even if they depend on
> different versions of core, 99% of the time it's likely to work. The
> version of core you'll end up running against will be determined by Maven's
> dependency mediation rules; the developer can explicitly override by
> specifying the version of core in their <dependencyManagement> section.
>
> The point about semantic versioning is that it will give the end-user
> better information to use when overriding.
>
>
>
>> Regards
>>
>> Rob
>>
>>
Re: [VOTE] adopt semantic versioning
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 13 December 2012 00:01, Robert Matthews <rm...@nakedobjects.org>wrote:
>
> However this is not a problem with Maven and it's plug-ins, I specify -
> very specifically - what version of a plug-in I want to use, but I can use
> that with version 3.0.2, 3.0.3 or 3.0.4 of Maven, it'll probably even work
> with version 2 as well.
>
> What am I missing?
>
In fact, in most cases you will also be able to do this in Isis... the
point is that it isn't a "certified release", and so the end-user is to
some extent risking JAR hell. But yes, you could take the latest
isis-wicket-viewer and isis-objectstore-jdo, even if they depend on
different versions of core, 99% of the time it's likely to work. The
version of core you'll end up running against will be determined by Maven's
dependency mediation rules; the developer can explicitly override by
specifying the version of core in their <dependencyManagement> section.
The point about semantic versioning is that it will give the end-user
better information to use when overriding.
>
> Regards
>
> Rob
>
>
Re: [VOTE] adopt semantic versioning
Posted by Robert Matthews <rm...@nakedobjects.org>.
What happens at the point shown below?
> For example
>
> * core 1.0.0 is released
> * isis-objectstore-jdo 1.0.0 is released, dependent on core 1.0.0
> * isis-viewer-wicket 1.0.0 is released, dependent on core 1.0.0
> * core 1.0.1 is released. This is NOT picked up by either of the above
> components.
> * isis-objectstore-jdo 1.0.1 is released, dependent on core 1.0.1. This
> also incorporates a number of its own bug fixes
> * core 1.1.0 is released, providing a new feature
> * isis-viewer-wicket 1.1.0 is released, using the new feature provided by
> core 1.1.0
If I am using isis-objectstore-jdo then will I not be able to use the
latest isis-viewer-wicket because the viewer only depends on an older,
but still valid version of core. If this logic is correct then even the
most minor fix will need the complete set of components to be re-released!
However this is not a problem with Maven and it's plug-ins, I specify -
very specifically - what version of a plug-in I want to use, but I can
use that with version 3.0.2, 3.0.3 or 3.0.4 of Maven, it'll probably
even work with version 2 as well.
What am I missing?
Regards
Rob