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"
Line 4: | Line 4: | ||
The jobs on [https://hudson.eclipse.org/sirius/ our HIPP] only publish "nightly" builds (using the script in <code>releng/org.eclipse.sirius.releng/publish-nightly.sh</code>), which end up in <code>/home/data/httpd/download.eclipse.org/sirius/updates/nightly</code> under names like <code>1.0.0-N20140605-075527</code>. Promotion of such a build as a milestone is currently a manual (but simple) process: | The jobs on [https://hudson.eclipse.org/sirius/ our HIPP] only publish "nightly" builds (using the script in <code>releng/org.eclipse.sirius.releng/publish-nightly.sh</code>), which end up in <code>/home/data/httpd/download.eclipse.org/sirius/updates/nightly</code> under names like <code>1.0.0-N20140605-075527</code>. Promotion of such a build as a milestone is currently a manual (but simple) process: | ||
− | + | * Login on <code>build.eclipse.org</code> using your Eclipse commiter credentials: <code>ssh $commiter_id@build.eclipse.org</code> | |
− | + | * Go into the root folder for Sirius update sites: <code>cd /home/data/httpd/download.eclipse.org/sirius/updates</code> or <code>cd downloads/sirius/updates</code> | |
− | + | * Copy the whole update-site you want to promote from <code>nightly</code> into <code>milestones</code>, under the final name. For example: <code>cp -a nightly/3.0.0-N20150503-075527 milestones/3.0.0M7</code> | |
− | + | * Also copy the archived version of the update-sites. To reduce disk usage a little, these archives are not promoted for each nightly individually, but only for the the latest build of a given stream. For example for Sirius 3.0.x, the zip files are located in <code>nightly/3.0.x</code>, so promoting the zipped versions is done by (for example) <code>cp nightly/3.0.x/org.eclipse.sirius*.zip milestones/3.0.0M7</code>. '''WARNING''': Because only one version of the archived update sites is kept per stream, the zip files are overwritten on each nightly build for that stream. Only copy the existing archives if you are 100% sure they correspond to the exact build you are promoting. Otherwise re-create them manually from the actual promoted repositories: | |
− | + | <code>cd milestones/3.0.0M7</code> | |
− | + | <code>cd luna</code> (repeat from here for each platform-specific variant, e.g. <code>kepler</code> and <code>mars</code>) | |
− | + | <code>zip -r ../org.eclipse.sirius-$(basename $(dirname $(pwd)))-$(basename $(pwd)).zip artifacts.jar content.jar features/ plugins/</code> (produces <code>org.eclipse.sirius-3.0.0M7-luna.zip</code>) | |
+ | <code>cd tests</code> | ||
+ | <code>zip -r ../../org.eclipse.sirius.tests-$(basename $(dirname $(pwd)))-$(basename $(pwd)).zip artifacts.jar content.jar features/ plugins/</code> (produces <code>org.eclipse.sirius.tests-3.0.0M7-luna.zip</code>) | ||
+ | * For '''S'''table snapshots, '''M'''ilestones and '''R'''elease '''C'''andidates, rename the zip files containing the archived repositories with the proper qualifier. The zip files should have names of the form <code>org.eclipse.sirius-3.0.0M7-mars.zip</code>, <code>org.eclipse.sirius.tests-2.0.6rc1-lune.zip</code>, etc. | ||
+ | * For actual releases (and optionaly for milestones), copy and adapt the <code>index.html</code> file from another release to the root of the milestone/release so that users who go to e.g. <code>http://download.eclipse.org/sirius/updates/releases/1.0.0/</code> instead of the platform-specific repo URL (<code>.../1.0.0/luna/</code> for example) get pointers to the URLs they are looking for instead of a "Not Found" error message. | ||
+ | * Update [[Sirius/Update_Sites|the list of available update sites]] on the wiki to mention the where the <code>nightly</code> for the <code>milestones</code> will be published. | ||
Promoting a release follows the same principles, except that it goes from <code>milestones</code> into <code>releases</code>. 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. | Promoting a release follows the same principles, except that it goes from <code>milestones</code> into <code>releases</code>. 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. |
Revision as of 05:05, 29 April 2015
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 simple) process:
- Login on
build.eclipse.org
using your Eclipse commiter credentials:ssh $commiter_id@build.eclipse.org
- Go into the root folder for Sirius update sites:
cd /home/data/httpd/download.eclipse.org/sirius/updates
orcd downloads/sirius/updates
- Copy the whole update-site you want to promote from
nightly
intomilestones
, under the final name. For example:cp -a nightly/3.0.0-N20150503-075527 milestones/3.0.0M7
- Also copy the archived version of the update-sites. To reduce disk usage a little, these archives are not promoted for each nightly individually, but only for the the latest build of a given stream. For example for Sirius 3.0.x, the zip files are located in
nightly/3.0.x
, so promoting the zipped versions is done by (for example)cp nightly/3.0.x/org.eclipse.sirius*.zip milestones/3.0.0M7
. WARNING: Because only one version of the archived update sites is kept per stream, the zip files are overwritten on each nightly build for that stream. Only copy the existing archives if you are 100% sure they correspond to the exact build you are promoting. Otherwise re-create them manually from the actual promoted repositories:
cd milestones/3.0.0M7
cd luna
(repeat from here for each platform-specific variant, e.g.kepler
andmars
)zip -r ../org.eclipse.sirius-$(basename $(dirname $(pwd)))-$(basename $(pwd)).zip artifacts.jar content.jar features/ plugins/
(producesorg.eclipse.sirius-3.0.0M7-luna.zip
)cd tests
zip -r ../../org.eclipse.sirius.tests-$(basename $(dirname $(pwd)))-$(basename $(pwd)).zip artifacts.jar content.jar features/ plugins/
(producesorg.eclipse.sirius.tests-3.0.0M7-luna.zip
)
- For Stable snapshots, Milestones and Release Candidates, rename the zip files containing the archived repositories with the proper qualifier. The zip files should have names of the form
org.eclipse.sirius-3.0.0M7-mars.zip
,org.eclipse.sirius.tests-2.0.6rc1-lune.zip
, etc. - For actual releases (and optionaly for milestones), copy and adapt the
index.html
file from another release to the root of the milestone/release so that users who go to e.g.http://download.eclipse.org/sirius/updates/releases/1.0.0/
instead of the platform-specific repo URL (.../1.0.0/luna/
for example) get pointers to the URLs they are looking for instead of a "Not Found" error message. - Update the list of available update sites on the wiki to mention the where the
nightly
for themilestones
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:
- 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 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"