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 paragraph.
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 http://aries.apache.org/development/versionpolicy 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: dev@aries.apache.org > Date: 08/18/2015 08:09 AM > Subject: Re: Fw: Versioning Policy > Sent by: Christian Schneider <cschneider...@gmail.com> > > 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 > > http://aries.apache.org/development/versionpolicy, but my main concern, > > whatever the policy, is consistency and understanding how the upcoming > > subsystems release should be versioned. What is the current Apache Aries > > versioning policy and where is it defined? Barring any responses, I will > > assume it is still described in the link above. > > > >> To: dev@aries.apache.org > >> Date: 08/13/2015 07:34 AM > >> Subject: Versioning Policy > >> > >> > >> > >> What is the versioning policy currently being used? Is it still based on > >> http://aries.apache.org/development/versionpolicy and the Aries > > versioning > >> plugin? If so, it's not clear to me how subsystems got a major version > >> bump. > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
