|
| Re: Oomph version management tool questions [message #1814791 is a reply to message #1814790] |
Wed, 18 September 2019 10:37   |
 Ed Merks
Messages: 33136
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...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
|
|
| Re: Oomph version management tool questions [message #1819546 is a reply to message #1819532] |
Fri, 17 January 2020 08:01 |
Ed Merks
Messages: 33136
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...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02173 seconds
] 
Search
Help
Register
Login
Home
