Am 17.08.2012 14:49, schrieb Ed Merks:
Hi,
Eike and I have been working on a tool for helping manage plugin
and feature versions (as well as other types of consistency
checks). API Tooling is very useful for keeping track of when you
should increment a plugin's major or minor version, but nothing
currently helps you manage your micro versions. It's very easy to
forget to increment the minor version after making a content
change (body of some method, for example) and it's hard to
remember whether you've already incremented the micro version for
the current stream. Our idea is to create a base line, i.e., to
keep track of all bundles and features as well as their versions
at the start of a stream along with digests so we know when the
contents of bundles and features change. A content change
requires an increment to the micro version and we create markers
(with quick fixes) to flag these. Feature inclusions are taken
into account, so if you change the version of a bundle, you're
prompted to appropriately increment the features that directly or
indirectly include that bundle. We can detect redundancies in
the includes, i.e., include a plugin that's already included by a
feature as well as breaking changes, e.g., removing a plugin. The
new "version builder" tool is mostly working now and is part of
CDO. We'll make it's feature available via CDO's p2 update
site...
I'd like to add that the original "CDO Release Engineering Version
Tool" is already ~2 years old and has since been used successfully
by the CDO team and a small number of other users. Ed and I have now
been working on these main areas:
- Make the bootstrap process more seamless (i.e. configuring the
projects and creating release specs + digests of released
projects).
- Extend the version validation to all 3 version segments of
features (originally it was mostly focused on micro versions of
plugins).
- Add more checks (e.g. schema builder declarations, .options
file validation, redundancy checks, etc.).
- Make incremental builds even faster.
- Factor out proper API and SPI.
The major remaining to-do items are:
- Enhance the feature redundancy checks to allow for duplicate
versions of the same included plugin/feature or referenced
license feature.
- Automatically detect and handle tool updates that change the
expected format of the persistent build state.
- Review various label strings and icons.
- Write documentation.
- Make the tool available through the marketplace.
In the process of making the tool attractive to a broader community
we've already renamed it to "Extended Version Management". For those
eager to see it, it's available through http://download.eclipse.org/modeling/emf/cdo/updates/integration
After the installation of the tool:
- Make sure that you've checked out the version of your code
that exactly reflects the state of your last release.
- Select the projects you want to manage.
- Right-click and choose "CDO Release Engineering" | "Add
Version Management".
- The following dialog will pop up:

- Enter the path to a file in an existing project (typically a
releng project). The file itself is created automatically if it
didn't already exist. It will also be recreated if it gets
deleted. Manually deleting this file is your way to create a new
release spec that properly reflects the released state of your
projects.
- The builder also creates an xyz.properties file next to the
xyz.xml file that you can modify to specify the type of the
current stream (integration=true makes the builder suggest micro
version increments of +100, while integration=false leads to +1
suggestions).
- The builder also creates an xyz.digest file next to the
xyz.xml file that captures the digests of the released projects
in a binary form. It's automatically recreated if the tool
recognizes a new and changed xyz.xml file.
- Optional: Depending on your SCM you may need to copy the 3
files out of your workspace to preserve them while you switch
back your workspace to the HEAD of the current stream/branch. I
think Git can preserve unstaged changes.
- Switch back your workspace to the HEAD of the current
stream/branch and copy the 3 files back to their original
location.
- The tool should now create various problem markers for your
projects if they've been changed since the last release.
- Most of them have quick fixes associated and can be
quick-fixed in masses.
We'd be very happy to receive early feedback because it seems
that releng is done very differently by different teams ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|