Skip to main content
Jump to: navigation, search

Papyrus Developer Guide/Release Process: How To/Prepare the GA Release

< Papyrus Developer Guide‎ | Release Process: How To
Revision as of 11:11, 29 May 2019 by Patrick.Tessier.cea.fr (Talk | contribs) (Papyrus Web page)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Check list to publish a release for papyrus project leader

This step is among the most important ones to take so do not be shy and you should annoy your project lead as much as necessary until this is handled !

Eclipse project page

Do not forget to amend/complete the page dedicated to the release here. Verify that all the associated bugs are listed and the new and noteworthy that were integrated are mentioned and references=d. If some bugs were not treated in this release migrate the milestone to the next release.

IP Log managment

  • Verifiy and generate the IP log and post an IP log review on the same page
  • If needed, create CQ but normaly all CQs could have be done before the review process
  • Then submit the review
  • A bug is generated that you must follow for example https://dev.eclipse.org/ipzilla/show_bug.cgi?id=16458 (NB: only the committers have access to the ipzilla)

Review process

Official release (post RC2)

After you have released all the candidates, there usually is a quiet week when all the projects are to check for breaking or critical bugs. This time can be used, at the earliest, to initiate the final stage of the release plan.

Update the RCP and the SDK versions

Do not forget that you will need to release the RCP corresponding to the release. therefore you should build a new one just after the final RC build and keep the artifacts to publish them the day you do the official release.
Do not forget to create a patch incrementing the SDK features and the RCP product in order to begin anew as soon as possible. (i.e. the day after you push the final RC artifacts to the Simrel repository). This patch should be contributed to a new Releng bug that will aggregate all the upcoming releng changes for the next release.

In order to avoid the disruption on the master branch, i.e. shutting down merges until the release, it is recommended to create a new branch based on the release tag and build the release RCP from it. You will have to create a new job on the Integration Instance (you can base it on the Master-RCP job for convenience but do not forget to change the branch). You will then have to modify some references so as to build/integrate against the release and not the nightly:

* papyrus.repo.main should point on the release (do no forget to either change or delete the override in the RCP job itself.
* papyrus.repo.toolsmiths can be updated as well depending on what you are including in the RCP.

The old textual release refenreces should also be updated to the new one as well as the splash screen. To that effect there is an updatable svg in the org.eclipse.papyrus.rcp plugin. From this svg you will be able to generate the required splash.bmp file; do not forget however that the file should not exceed 400 kBs. You will need to be aware of the limitations mentioned in the following eclipse branding page.

Once all that is done you would be able to use the Publish-RCP job that will take care of the rest for you. Once the RCPs are on the eclipse servers a final check on the sum and integrity of the archive should be done and you are all set.

Preparing the release

To prepare the official release, the final build will have to be copied from milestones/<versionnumber>/<RCx> to releases/<versionname>/<releasenumber>/ (e.g. cp -r ./milestones/2.0/RC4/. ./releases/neon/2.0.2/). This will allow the indexing of the future release and start the mirroring process.
The copied content should be hidden from the installers to synchronize the release with the train. Usually, as mentionned, moving the artifacts, content, category and p2.index files to a dummy hidden directory should be enough (just go in the folder and find . -maxdepth 1 -type f -exec mv {} hide/ \;).
You should test what you have done by copy/pasting the hidden update site in your installer and verifying that eclipse cannot read any of its content.

You should also start to remove/archive old milestone build as they are not needed anymore and take space (see Maintenance). You can keep the RC builds if you have to but that's about it. Do not forget to remove the references contained in the composites (artifact and content).

To do this you will have to log yourself to the build.eclipse.org repository via an ssh connection (e.g. ssh <login>@build.eclipse.org).


Papyrus Web page

  • Prepare a patch with the updated News and Downloads page in order to push them the day of the release. For this you will have to fetch the papyrus-Web repository here.
  • Update the news, the RCP references and the releases/nightly references provided by the news.xml and download.html for the static page and from there you should be set.
  • Update relatives

Back to the top