Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Correct bundle versioning for GEF 3.9.2 Luna release?

Am 26.03.2014 03:59, schrieb David M Williams:
In addition to, or as a supplement to, the tool that Eike mentioned, There is a "versioning guidelines" document at

It suggests that once a bundle changes in "the next" development cycle, to increment (at least) the service field by +100. This is to "leave room" for you to come out with a "maintenance patch" or similar if you decided one was needed, so it then the long term maintenance stream could "grow" into the values or 3.9.3, 3.9.4, or what ever, while "the next" release could be sure to be higher at at 3.9.100. And ideally, bundles are versioned independently of of each other other (that is, not changed simply for the sake of keeping them all the same -- thought know a lot of people don't do that) ... and then the feature version is determined by "the biggest change" in the bundles it contains.  

Now, perhaps you can tell us if the tool Eike, et. al, have developed gives you the same answer ...
Not sure if Alexander already had the time to try out the tool, but I certainly can ;-)

Yes, the Version Management tool gives the exactly same answers to the topics you've listed and even some more. In fact we've used the document you've pointed to as guideline / requirements for the tool.

All you need to do is:

1) Install the Version Management feature from

2) Select the plugin and feature projects you want to have managed by the tool and click "Configure -> Add Version Management...".

3) Enter the path to the location in the workspace where you want the tool to store your binary baseline:

4) The baseline is automatically created by the tool if it doesn't exist. For first time usage you may want to (a) checkout the sources of your last release, (b) enable the tool, (c) create a backup copy of the created baseline files, (d) checkout the tip of your branch and (e) restore the backup copy in the same location. This way the tool will create error markers for the micro changes between your last release and now.

5) In the generated file set the "baseline.for.integration"  property to true for +100 suggestions or to false for +1 suggestions (maintenance).

6) Use (mass) quickfixes to solve the version errors:

7) After your next release just delete the release.xml and the tool will create a new baseline for you. Please note that the incremental builder will define internal build dependencies from the managed projects onto the project that contains the release.* files, so don't place them in a project where you tend to apply a lot of other changes to avoid frequent full builds. Ideally you choose either a dedicated project or a feature project that you rarely change.



I'm sure it will be less wordy about it. :)

From:        Alexander Nyßen <alexander.nyssen@xxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        03/23/2014 09:39 PM
Subject:        [cross-project-issues-dev] Correct bundle versioning for GEF 3.9.2        Luna release?
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

I am not sure whether this is the right location to ask, but I have a question w.r.t. to the correct versioning of our bundles for the Luna 3.9.2 release of GEF:

For Kepler SR1 we have shipped GEF 3.9.1 (feature-version), which contained org.eclipse.draw2d 3.9.0 (which actually remained unchanged from 3.9.0 release) and org.eclipse.gef.3.9.0 (which should actually have been 3.9.1, because there was a service level change from 3.9.0, but which was not updated either). Both bundles have changed again since the GEF 3.9.1 release (while again only service-level bugfixes). As GEF 3.9.2 (feature-version) is developed on the master branch (Luna stream), while GEF 3.9.1 (feature-version) was developed on the Kepler maintenance stream, should we rather increase the versions of both bundles to 3.9.100 now to indicate we are on a new development stream, or rather to 3.9.1 (or in case of org.eclipse.gef to a more appropriate 3.9.2 because 3.9.1 should already have been included in GEF 3.9.1)?

Best Regards
Dr. Alexander Nyßen

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] _______________________________________________
cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Back to the top