Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Sirius/Releng"
m (→Cutting a maintenance branch) |
|||
Line 4: | Line 4: | ||
There are several steps needed to create a new maintenance branch for a release. Assuming <code>master</code> is at version 1.0.0, which is released, and that the next version will be 2.0.0, we must: | There are several steps needed to create a new maintenance branch for a release. Assuming <code>master</code> is at version 1.0.0, which is released, and that the next version will be 2.0.0, we must: | ||
− | # Create a new Git branch named <code>v1.0.x | + | # Create a new Git branch named <code>v1.0.x</code>, starting from the exact commit containing the final released 1.0.0 version: <code> git branch v1.0.0x v1.0.0</code> (assuming the tag for <code>v1.0.0</code> has been created). |
# In the new <code>v1.0.x</code>, bump the version number to 1.0.1 to be ready for the next service release on that branch. | # In the new <code>v1.0.x</code>, bump the version number to 1.0.1 to be ready for the next service release on that branch. | ||
# On the [https://hudson.eclipse.org/sirius/ Sirius HIPP], create a new job named <code>sirius-1.0.x</code>, starting from a copy of <code>sirius-master</code>. Adjust the job description and the name of the branch to build. Normally that is all that is needed, the publication script knows were to publish the build if the version bump was done correctly. | # On the [https://hudson.eclipse.org/sirius/ Sirius HIPP], create a new job named <code>sirius-1.0.x</code>, starting from a copy of <code>sirius-master</code>. Adjust the job description and the name of the branch to build. Normally that is all that is needed, the publication script knows were to publish the build if the version bump was done correctly. |
Revision as of 04:55, 11 June 2014
Notes, rules and recipes related to Sirius release engineering.
Cutting a maintenance branch
There are several steps needed to create a new maintenance branch for a release. Assuming master
is at version 1.0.0, which is released, and that the next version will be 2.0.0, we must:
- Create a new Git branch named
v1.0.x
, starting from the exact commit containing the final released 1.0.0 version:git branch v1.0.0x v1.0.0
(assuming the tag forv1.0.0
has been created). - In the new
v1.0.x
, bump the version number to 1.0.1 to be ready for the next service release on that branch. - On the Sirius HIPP, create a new job named
sirius-1.0.x
, starting from a copy ofsirius-master
. Adjust the job description and the name of the branch to build. Normally that is all that is needed, the publication script knows were to publish the build if the version bump was done correctly. - On the
master
branch, bump the version number to the next planned version, e.g. 2.0.0. - Update the list of available update sites on the wiki to mention the where the nightlies for the maintenance branch will be published.
- Announce the new branch and update-site on the
sirius-dev
mailing-list.
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 pom.xml
, feature.xml
, about.ini
, MANIFEST.MF
, and in the publication script. It excludes the plugin.xml
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 git diff
).
Check the result builds correctly with:
mvn clean package
and check in packaging/org.eclipse.sirius.update/target/repository
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 @since
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"