Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Sirius/Releng"

(→‎Version bump)
Line 26: Line 26:
 
== Version bump ==
 
== 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:
+
To bump the Sirius version, for example from 2.0.0 to 2.0.1, most of the changes required can be performed automatically. From a clean state, first 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
+
     mvn org.eclipse.tycho:tycho-versions-plugin:0.21.0:set-version -DnewVersion=2.0.1-SNAPSHOT
−
    sed -i -e 's/VERSION="1\.0\.0"/VERSION="2.0.0"/' releng/org.eclipse.sirius.releng/publish-nightly.sh
+
    mvn -f packaging/org.eclipse.sirius.parent/pom.xml org.eclipse.tycho:tycho-versions-plugin:0.21.0:set-version -DnewVersion=2.0.1-SNAPSHOT
  
−
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>).
+
These use the Tycho <code>set-version</code> goal to update the versions in all <code>pom.xml</code>, <code>feature.xml</code>, and <code>MANIFEST.MF</code>. For <code>MANIFEST.MF</code>, the version of all exported packages is udpated, but not the <code>Require-Bundle</code> and <code>Import-Package</code> clauses (which is normal).
  
−
'''NOTE''': The instructions above will blindly update all the versions of all the exported packages, not just the bundles. In practice even if many packages of a given bundle break APIs in the next version, most will probably not. It would be better to follow precise semantic versionning rules (but as of this writing we have not setup anything to do this automatically).
+
The Tycho plug-in does not handle everything, so after that you need to manually update the coordinates of the Target Platform artifact as referenced in <code>packaging/org.eclipse.sirius.parent/pom.xml</code> and <code>packaging/org.eclipse.sirius.tests.parent/pom.xml</code>.
  
−
Check the result builds correctly with:
+
Next, manually edit the version number of the parent POM for <code>packaging/org.eclipse.sirius.tests.parent/pom.xml</code>, and issue:
  
−
     mvn clean package
+
     mvn -f packaging/org.eclipse.sirius.tests.parent/pom.xml org.eclipse.tycho:tycho-versions-plugin:0.21.0:set-version -DnewVersion=2.0.1-SNAPSHOT
  
−
and check in <code>packaging/org.eclipse.sirius.update/target/repository</code> that all features and plug-ins have the correction version.
+
This takes care of the test plug-ins and feature, which are not part of the "main" build.
 +
 
 +
The version number also appears in <code>about.ini</code> files, which are not handled by Tycho. The following command takes care of them:
 +
 
 +
    git ls-files '**/about.ini' | while read f; do sed -i -e 's/Version 2\.0\.0/Version 2.0.1/g' $f; done
 +
 
 +
You can then perform a full build, which should be successful:
 +
 
 +
    ./build-all.sh
 +
 
 +
and check that all plug-ins and features (except some tests and samples) have the correct version:
 +
 
 +
    find . -path '*/target/repository/**/*.jar' | grep -v '2\.0\.1'
  
 
See if any reference was forgotten with
 
See if any reference was forgotten with
  
−
     git grep -l "1\.0\.0"
+
     git grep -l "2\.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.
 
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.
Line 49: Line 61:
 
Once you are confident in the result, commit (and then push) using a message of this form:
 
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"
+
   git commit -s -m "[version] Bump version to 2.0.1"
  
 
[[Category:Sirius]]
 
[[Category:Sirius]]

Revision as of 06:25, 4 November 2014

Notes, rules and recipes related to Sirius release engineering.

Promoting a Milestone or Release

The jobs on our HIPP only publish "nightly" builds (using the script in releng/org.eclipse.sirius.releng/publish-nightly.sh), which end up in /home/data/httpd/download.eclipse.org/sirius/updates/nightly under names like 1.0.0-N20140605-075527. Promotion of such a build as a milestone is currently a manual (but trivial) process:

  1. Login on build.eclipse.org using your Eclipse commiter credentials: ssh $commiter_id@build.eclipse.org
  2. Go into the root folder for Sirius update sites: cd /home/data/httpd/download.eclipse.org/sirius/updates or cd downloads/sirius/updates
  3. Simply copy the whole update-site you want to promote from nightly into milestones, under the final name. For example: cp -a nightly/1.0.0-N20140605-075527 milestones/1.0.0rc4
  4. Optionally, copy the basic index.html file at the root of the milestone so that users who go to e.g. http://download.eclipse.org/sirius/updates/milestones/1.0.0M6/ instead of the platform-specific repo URL (.../1.0.0M6/luna/ for example) get pointers to the URLs they are looking for instead of a "Not Found" error message: cp milestones/1.0.0M6/index.html milestones/1.0.0rc4
  5. Update the list of available update sites on the wiki to mention the where the nightly for the milestones will be published.

Promoting a release follows the same principles, except that it goes from milestones into releases. Nothing should be promoted as a final release that has not been promoted first as a milestone (preferably with a "release candidate" status), and thouroughly tested.

Also remember that this recipe only deals with the "copying the bytes" parts of the process: an actual release involves much more than that!

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:

  1. 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 for v1.0.0 has been created).
  2. 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.
  3. On the Sirius HIPP, create a new job named sirius-1.0.x, starting from a copy of sirius-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.
  4. On the master branch, bump the version number to the next planned version, e.g. 2.0.0.
  5. Update the list of available update sites on the wiki to mention the where the nightlies for the maintenance branch will be published.
  6. Announce the new branch and update-site on the sirius-dev mailing-list.

Version bump

To bump the Sirius version, for example from 2.0.0 to 2.0.1, most of the changes required can be performed automatically. From a clean state, first issue the following commands: 

   mvn org.eclipse.tycho:tycho-versions-plugin:0.21.0:set-version -DnewVersion=2.0.1-SNAPSHOT
   mvn -f packaging/org.eclipse.sirius.parent/pom.xml org.eclipse.tycho:tycho-versions-plugin:0.21.0:set-version -DnewVersion=2.0.1-SNAPSHOT

These use the Tycho set-version goal to update the versions in all pom.xml, feature.xml, and MANIFEST.MF. For MANIFEST.MF, the version of all exported packages is udpated, but not the Require-Bundle and Import-Package clauses (which is normal).

The Tycho plug-in does not handle everything, so after that you need to manually update the coordinates of the Target Platform artifact as referenced in packaging/org.eclipse.sirius.parent/pom.xml and packaging/org.eclipse.sirius.tests.parent/pom.xml.

Next, manually edit the version number of the parent POM for packaging/org.eclipse.sirius.tests.parent/pom.xml, and issue: 

   mvn -f packaging/org.eclipse.sirius.tests.parent/pom.xml org.eclipse.tycho:tycho-versions-plugin:0.21.0:set-version -DnewVersion=2.0.1-SNAPSHOT

This takes care of the test plug-ins and feature, which are not part of the "main" build.

The version number also appears in about.ini files, which are not handled by Tycho. The following command takes care of them: 

   git ls-files '**/about.ini' | while read f; do sed -i -e 's/Version 2\.0\.0/Version 2.0.1/g' $f; done

You can then perform a full build, which should be successful: 

   ./build-all.sh

and check that all plug-ins and features (except some tests and samples) have the correct version: 

   find . -path '*/target/repository/**/*.jar' | grep -v '2\.0\.1'

See if any reference was forgotten with 

   git grep -l "2\.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.1"
Retrieved from "https://wiki.eclipse.org/index.php?title=Sirius/Releng&oldid=373169"

Back to the top