| Eike and David, thanks for your detailed answers!
David, indeed I was aware about the versioning guidelines document in the wiki, but I was not exactly sure about whether I really had understood it correctly. It seems I had, so I will probably have to update both plug-ins to 3.9.100 because we are in a new release stream. Thanks for the clarification.
Eike, thanks for your support. I already took a first glimpse at the tool but did not fully get it to work. The problem was I did not understand how the tool actually computes its baseline, i.e. I did not know I had to apply step 4 (I thought it would probably use the API-baselines I had defined). That makes things a lot clearer now...
While the guideline document is not so explicit about this, Eikes tool actually also proposes to update features versions according to the version changes of (transitively) contained projects (I already saw that in my first attempt). That seems to be logical at some point, because if we want to use 3.9.100 versions for bundles in the release stream, so that can later use 3.9.3, 3.9.4, etc. in the maintenance stream without conflict, it would only be reasonable to do so for the containing features as well.
Having said so, it seems I will then have to announce a GEF 3.9.100 release instead of a 3.9.2 release for Luna, right?
Best Regards Alexander 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.
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
http://wiki.eclipse.org/Version_Numbering
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 http://download.eclipse.org/modeling/emf/cdo/updates/integration
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:<jjjbiggd.png>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 release.properties 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: <eaaifbij.png>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. Cheers /Eike ---- http://www.esc-net.dehttp://thegordian.blogspot.comhttp://twitter.com/eikestepperI'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
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
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
|
