Eclipse Community Forums: Oomph » Oomph version management tool questions

Help

Home

Home » Eclipse Projects » Oomph » Oomph version management tool questions

Show: Today's Messages :: Show Polls :: Message Navigator

Oomph version management tool questions [message #1814790]

Wed, 18 September 2019 09:50

Lutz Wrage

Messages: 159
Registered: July 2009

Senior Member

On the project overview page I found that Oomph provides "A builder for managing bundle micro versions and feature versions relative to a baseline, augmenting PDE's API Tools." I installed the Oomph Version Management feature which seems to provide this functionality. I found that I add version management to plugin projects and that there are preferences. It marks missing versions in manifest files, etc.
Unfortunately I didn't find any documentation (maybe I looked in the wrong places, I hope I didn't miss something obvious) so I have a couple of questions:

What is the exact functionality that the tool adds?
What's the workflow to switch to a new release?
Also, are the generated release.xml, etc files meant to be put under version control?
There can be multiple releases in the preferences: Should I have one release per feature or should there be one for my product.

If there is documentation, maybe even just some blog post that explains the tool, I'd appreciate if you could point me to it.

Thanks in advance!

Report message to a moderator

Re: Oomph version management tool questions [message #1814791 is a reply to message #1814790]

Wed, 18 September 2019 10:37

Ed Merks

Messages: 30892
Registered: July 2009

Senior Member

Sorry, we didn't write any documentation. We use this tool ourselves in Oomph, CDO, and EMF.

This tool builds a release.xml and a release.digest and the properties are managed by the release.properties. E.g., you'll see them here:

https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.util

What I always do at the start of a release is delete each release.xml; a new one is then generated.

Yes, as you can see where we use it, the release.xml, release.digest, and release.properties should be in version control.

How you maintain the releases is quite flexible. For EMF I maintain multiple release.xml files, but in the end, I end up deleting them all at the start of a release and generate new ones, so probably it would have been easier to have a single one; because one puts them in version control, one could maintain multiple branches in GIT, e.g., to support a maintenance (where you'd increment the versions differently) stream in addition to the "master" stream. But we no longer provide maintenance stream supports (because Eclipse does a full release 4 times per year.

Sorry, there is no documentation. It's super helpful tool for us personally (for the Eclipse git repositories we manage ourselves) ; we never forget to increment versions and there are always quick fixes for the version problems, so it's super easy to ensure that versions are properly and appropriately incremented. Of course we should be using API tooling too, but that only helps with the x.y part of the x.y.z version, not the z part of the x.y.z version...

Report message to a moderator

Re: Oomph version management tool questions [message #1814792 is a reply to message #1814791]

Wed, 18 September 2019 11:42

Lutz Wrage

Messages: 159
Registered: July 2009

Senior Member

Thanks, that was helpful.

Report message to a moderator

Re: Oomph version management tool questions [message #1819462 is a reply to message #1814792]

Wed, 15 January 2020 19:15

Lutz Wrage

Messages: 159
Registered: July 2009

Senior Member

I have a couple more questions about release.properties

- I assume root.projects is there to list projects that don't need to be included elsewhere. Is that correct?
- What's the meaning of baseline.for.integration, ignored.references, show.deviations, provide.service? I looked at the source code, but I couldn't figure it out.

Report message to a moderator

Re: Oomph version management tool questions [message #1819473 is a reply to message #1819462]

Thu, 16 January 2020 06:49

Ed Merks

Messages: 30892
Registered: July 2009

Senior Member

The root.projects are the projects that are no included (via feature and bundle dependencies), but other projects in the workspace.

baseline.for.integration determines whether the increment of the micro version will be .100 versus .1.
ignored.references are elements that will be ignored when determining if a feature needs to be incremented or not; it's mostly used by quickfix when you tell it to ignore a specific need to increment something
provide.service determines whether changes will require to increment the micro version on the minor version, e.g., for Oomph, when anything changes, we increment to 1.16 right now rather than to 1.15.100 or 1.15.1. If you're going to use the version builder tool to increment micro versions then you'll also need to use API tools to help with incrementing minor versions.
show.deviations will produce warning markers for feature problems showing which included bundle/feature has changed requiring the feature itself to be incremented.

Report message to a moderator

Re: Oomph version management tool questions [message #1819532 is a reply to message #1819473]

Fri, 17 January 2020 01:33

Lutz Wrage

Messages: 159
Registered: July 2009

Senior Member

Thanks for the explanation!

I now found preferences Oomph -> Version Management. What do the possible values for "Check Mode" and "Lower Bound Check Mode" mean?

Report message to a moderator

Re: Oomph version management tool questions [message #1819546 is a reply to message #1819532]

Fri, 17 January 2020 08:01

Ed Merks

Messages: 30892
Registered: July 2009

Senior Member

For check mode, it controls how to handle the case that some dependency in the workspace has a version builder attached or not. E.g., if you add a new project and add it as a dependency to some version controlled project it would get flagged as needing the version builder.

For lower bound check mode, it controls how the check the lower bounds on dependencies. I.e., should the lower bound match the current version and should that check be done for projects in the same release, for projects in any release, or for all dependencies, even ones in the target platform...

Report message to a moderator

Previous Topic:	Eclipse download
Next Topic:	Install eclipse with a bundled jre (jre copied inside eclipse installation)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Feb 20 13:58:56 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter