|
|
| (18 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | Notes, rules and recipes related to Sirius release engineering.
| |
| | | | |
| − | == Version bump ==
| |
| − |
| |
| − | To bump the Sirius version, for example from 1.0.0 to 2.0.0, most of the changes required can be performed automatically. From a clean state, issue the following commands:
| |
| − |
| |
| − | git grep -l "1\.0\.0" -- '*.xml' '**/*.xml' '**/MANIFEST.MF' '**/about.ini' | grep -v plugin.xml | while read f; do sed -i -e 's/1\.0\.0/2.0.0/g' $f; done
| |
| − | sed -i -e 's/VERSION="1\.0\.0"/VERSION="2.0.0"/' releng/org.eclipse.sirius.releng/publish-nightly.sh
| |
| − |
| |
| − | This changes the version number in all <code>pom.xml</code>, <code>feature.xml</code>, <code>about.ini</code>, <code>MANIFEST.MF</code>, and in the publication script. It excludes the <code>plugin.xml</code> files because they contain the metamodel URIs, which should only change if the metamodel change in incompatible ways (and even then, in practice we don't change these and rely on our migration framework). Obviously this assumes nothing else than Sirius in the whole code base is using "1.0.0" as a version number, so '''carefully review the patch before commiting it''' (e.g. visually review the output of <code>git diff</code>).
| |
| − |
| |
| − | Check the result builds correctly with:
| |
| − |
| |
| − | mvn clean package
| |
| − |
| |
| − | and check in <code>packaging/org.eclipse.sirius.update/target/repository</code> that all features and plug-ins have the correction version.
| |
| − |
| |
| − | See if any reference was forgotten with
| |
| − |
| |
| − | git grep -l "1\.0\.0"
| |
| − |
| |
| − | It is normal to have references to the old version in <code>@since</code> annotations in the Java code, in the metamodels nsURIs, and in the release notes.
| |
| − |
| |
| − | Once you are confident in the result, commit (and then push) using a message of this form:
| |
| − |
| |
| − | git commit -s -m "[version] Bump version to 2.0.0"
| |
