aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John W Ross <>
Subject Re: Fw: Versioning Policy
Date Tue, 18 Aug 2015 13:39:03 GMT
There were a lot of discussions a couple of years ago about moving to a 
release by module scheme rather than release by distribution, and, at one 
time at least, I recall that the consensus was to use release by module. 
The last two or three subsystem releases appear to follow the release by 
distribution scheme where subsystem-api, subsystem-core, and 
subsystem-bundle all have the same version (e.g., subsystem-2.0.2). It 
sounds like you are advocating for release by distribution in your last 

Under the release by module scheme, for example, if only bug fixes 
occurred to subsystem-core, I would release just the one module with a 
micro version bump but not subsystem-api, so there would be a divergence 
in versions across modules within the same distribution. As an "uber 
bundle", the subsystem-bundle module should be released whenever one of 
its contained components changes I guess, although I wish we didn't have 
uber bundles at all.

The versioning policy described in is great when there's a 
well-defined API, as in Subsystems. However, I imagine it can get a bit 
hairy with things like aries-util.

I understand your point about possibly incrementing a minor version when 
new functionality is introduced; however, new functionality seems unlikely 
without a corresponding API change when a well-defined one exists.

> To:
> Date: 08/18/2015 08:09 AM
> Subject: Re: Fw: Versioning Policy
> Sent by: Christian Schneider <>
> I think for the most part the version policy is still correct.
> In my opinion the focus should be on versioning the packages correctly 
> and according to OSGi semantic versioning rules.
> We currently use the aries version plugin to check for this. As the 
> maven bundle plugin now also offers the semantic versioning checks I 
> will experiment with switching to it and report how well it works.
> For the bundle version I think the version policy described makes sense 
> in general but I would not mind if the version jump is bigger than the 
> jump described in the policy.
> Sometimes no exported package changes but you still have new 
> functionality. So a increasing the minor version instead of the bugfix 
> version makes sense. After all the bundle version does not mean much in 
> OSGi technically.
> Not sure about the subsystems version bump as I did not follow the 
> changes. I looked up the svn change of the version and it was done by 
> Jean-Baptiste Onofré. Unfortunately he is on vacation at the moment.
> Btw. The policy document even is valid to a large degree for the 
> releases by subproject that I started with the jpa subproject. The only 
> difference is that all bundles in the subproject have the same bundle 
> version. I typically derive the next bundle version from the largest 
> change in the exported packages of all bundles in  the subproject. So 
> basically it is the same rule as in the policy document just on a 
> different level.
> Christian
> On 18.08.2015 14:29, John W Ross wrote:
> > No discussion on this? I personally prefer the policy outlined in
> >, but my main 
> > whatever the policy, is consistency and understanding how the upcoming
> > subsystems release should be versioned. What is the current Apache 
> > versioning policy and where is it defined? Barring any responses, I 
> > assume it is still described in the link above.
> >
> >> To:
> >> Date: 08/13/2015 07:34 AM
> >> Subject: Versioning Policy
> >>
> >>
> >>
> >> What is the versioning policy currently being used? Is it still based 
> >> and the Aries
> > versioning
> >> plugin? If so, it's not clear to me how subsystems got a major 
> >> bump.
> -- 
> Christian Schneider
> Open Source Architect

View raw message