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 "Papyrus Developer Guide/Release Process: How To/Prepare the GA Release"

(Papyrus Web page)
(One intermediate revision by one other user not shown)
Line 10: Line 10:
 
===IP Log managment===
 
===IP Log managment===
 
* Verifiy and generate the IP log and post an IP log review on the same page
 
* 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
+
* If needed, create CQ. Usualy, all CQs should have be done before the review process. You can view the process [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Contribution_Questionaire here].
 
* Then submit the review
 
* 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)
 
* 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)
Line 43: Line 43:
  
 
To prepare the official release, the final build will have to be copied from <code>milestones/<versionnumber>/<RCx></code> to <code>releases/<versionname>/<releasenumber>/</code> (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.<br/>
 
To prepare the official release, the final build will have to be copied from <code>milestones/<versionnumber>/<RCx></code> to <code>releases/<versionname>/<releasenumber>/</code> (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.<br/>
The copied content should be [https://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#How_is_a_final_build_made_.22invisible.22_until_release.3F '''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 <code>find . -maxdepth 1 -type f -exec mv {} hide/ \;</code>).<br/>
+
The copied content should be [https://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#How_is_a_final_build_made_.22invisible.22_until_release.3F '''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 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.<br/><br/>
+
 
You should also start to remove/archive old milestone build as they are not needed anymore and take space (see [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Release_Process:_How_To#Maintenance 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).
 
You should also start to remove/archive old milestone build as they are not needed anymore and take space (see [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Release_Process:_How_To#Maintenance 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'').
 
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 ===
 
=== Papyrus Web page ===

Revision as of 10:57, 19 November 2020

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. 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)

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. 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

Back to the top