| Oomph version management tool questions [message #1814790] |
Wed, 18 September 2019 05:50  |
Eclipse User |
|
|
|
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!
|
|
|
| Re: Oomph version management tool questions [message #1814791 is a reply to message #1814790] |
Wed, 18 September 2019 06:37  |
| Eclipse User |
|
|
|
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...
|
|
|
|
|
|
|
| Re: Oomph version management tool questions [message #1819546 is a reply to message #1819532] |
Fri, 17 January 2020 03:01 |
| Eclipse User |
|
|
|
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...
|
|
|
Powered by
FUDForum. Page generated in 0.14520 seconds
Home