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:
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:
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.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
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
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
|
