So the "release by sub projects" methodology would follow the package and bundle versioning methods described in http://aries.apache.org/development/versionpolicy, with the addition of "rounding up" the largest version increment out of all the bundles to apply to the project as a whole?
As an example, if only bug fixes are made to subsystem-core resulting in a micro version bump to 2.0.3, we would want to also release subsystem-api, subsystem-core, subsystem-bundle, and subsystem-obr at version 2.0.3 even though nothing changed in subsystem-api or subsystem-obr? Right now, the version specified in the POM translates into the bundle version as it appears in the manifest. Are we talking about forming a separation between the bundle versions as they appear in the bundle manifests and the released project version as it appears in the POMs, or do they remain in sync? > From: Christian Schneider <ch...@die-schneider.net> > To: dev@aries.apache.org > Date: 08/18/2015 08:55 AM > Subject: Re: Fw: Versioning Policy > Sent by: Christian Schneider <cschneider...@gmail.com> > > I started a discussion "[Discuss] Release whole sub projects instead of > individual bundles" on 2015-05-20. In this thread we agreed to allow to > release by subproject and also to move to that versioning scheme over > time. For details on pros and cons you can refer to the discussions. > > I was not aware that subsystems was changed to that scheme already but > it would be a good explanation for the version bump. > > Btw. I am currently working on transaction to also move it to that > scheme. There I even have to bump the version to 3.0.0 as the > transaction.jms module already exists in version 2.0.0. > > Christian > > On 18.08.2015 15:39, John W Ross wrote: > > 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 > >> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
