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.
Papyrus Developer Guide/Release Process: How To/Prepare the GA Release
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.
- update information for the version to release https://projects.eclipse.org/projects/modeling.mdt.papyrus
IP Log managment
- Verifiy and generate the IP log and post an IP log review on the same page
- If needed, create CQ. Usualy, all CQs should have be done before the review process. You can view the process here.
- 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)
- Could be done as the same time as IP log
- Go to the page https://projects.eclipse.org/projects/modeling.mdt.papyrus
- Launch the review for the release. when there is review, an eye icon is displayed on the line
- An issue is generated that you must follow for example : https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/406
- After the IP log
- You will need to ask for a release approbation by you modeling PMC and contribute it to the 'release Bug' as illustrated by: https://www.eclipse.org/lists/modeling-pmc/msg04604.html. This can be obtained by searching for Archives modeling-pmc in most search engines.
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 (to keep every information on the image you should first generate from svg to png then from png to bmp); 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
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. This can be done through the Papyrus-Web repository by adding the new release to the hiddenBuilds list and adding an empty index.html file to the folder to prevent users from browsing through the server links. 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