Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Bundle Version Management

Am 17.08.2012 14:49, schrieb Ed Merks:

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

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 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 ;-)



Back to the top