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.
Difference between revisions of "OCL/Dev/Releng/Quiet Week"
< OCL
(→Prepare the releases p2 repository) |
(→Quiet Week) |
||
| (42 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | In this wiki entry we explain the releng bits that may be done during the ''quiet week'', particularly to the Eclipse OCL project. You may find some general information about the '' | + | In this wiki entry we explain the releng bits that may be done during the ''quiet week'', particularly to the Eclipse OCL project. You may find some general information about the ''quiet week'' in the [[ Juno/Final_Daze | Simultaneous Release Final Daze]] documentation (Juno, for the time of writing). |
The main purpose of the quite week activities is preparing the downloadable zips and the release p2 repository in its final location so that they are properly mirrored across the different mirror servers prior to the final release date, taking into account that the content can't be available for download until that date. The releng tasks to be done are explained in two blocks, the tasks during the [[#Quite Week | Quite Week]] and those tasks which must be done the [[#Final Release Day | Final Release Day]]. | The main purpose of the quite week activities is preparing the downloadable zips and the release p2 repository in its final location so that they are properly mirrored across the different mirror servers prior to the final release date, taking into account that the content can't be available for download until that date. The releng tasks to be done are explained in two blocks, the tasks during the [[#Quite Week | Quite Week]] and those tasks which must be done the [[#Final Release Day | Final Release Day]]. | ||
| − | = | + | =Quiet Week= |
| − | The following are the Eclipse OCL | + | The following are the Eclipse OCL usual releng tasks to be accomplished during what was once the ''quiet week''. Since moving to a four release per year cadence, the ''quiet week'' is at best a couple of days. Now that ssh access to build.eclipse.org is more restricted, many of the former ''quiet week'' activities are imporactiocal and what is practical should be performed as late as possible in the final SimRel Release Candidate. |
| − | == | + | ==Build the final release== |
| + | Perform an R-build with an alias of the release name. Do this as late as practical before the final SimRel build so that the R-build can be contributed to the SimRel aggregator. Do this as late as practical before the final SimRel build so that the R-build can be contributed to the SimRel aggregator. Once built and promoted, disable the Promoter job to prevent any accidental re-builds until the project moves on to a new version number. Then the Promoter Job can be re-enabled. | ||
| − | + | ==Archive old releases== | |
| − | + | Older download ZIPs are moved to archive: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | *Edit the '''/mdt/downloads/extras-ocl.php''' file to add the redirections for archived releases | |
| − | + | *Copy the releases to archive | |
| + | cd ~/downloads/modeling/mdt/ocl/downloads/drops | ||
| + | mv 5.0.5 /home/data/httpd/archive.eclipse.org/modeling/mdt/ocl/downloads/drops | ||
| + | <del>*Make sure the archive is useable | ||
| + | For each new archived R folder that doesn't have an index.php</del> | ||
| − | + | <del> cp ../../3.1.0/R201106061427/index.php .</del> | |
| − | + | The default Eclipse Foundation archive.eclipse.org 404 page has a "Show Directory Contents." that provides similar/better functionality than the traditional project index.php. | |
| − | + | Older P2 repos are moved to archive: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * | + | *Copy the repo to archive |
| − | + | cd ~/downloads/modeling/mdt/ocl/updates/releases | |
| − | + | ant -f /shared/modeling/tools/promotion/manage-composite.xml remove -Dchild.repository=5.0.5 | |
| − | + | mv 5.0.5 /home/data/httpd/archive.eclipse.org/modeling/mdt/ocl/updates/releases | |
| − | + | cd /home/data/httpd/archive.eclipse.org/modeling/mdt/ocl/updates/releases | |
| − | + | ant -f /shared/modeling/tools/promotion/manage-composite.xml add -Dchild.repository=5.0.5 | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | == | + | ==Update the Help Info Center== |
| − | + | The Help Info Center is now populated automatically. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | <del>With every release a bugzilla is created so that every project can publish where the doc plugin is located in the new release repository. We will usually need to keep an eye to the cross-project-issues mailing list to catch the proper bugzilla up (Following the cross-project dot inbox @at eclipse dot org bugzilla account may also help). In the corresponding ''Juno'' release bugzilla [https://bugs.eclipse.org/bugs/show_bug.cgi?id=379598 379598] , you may find different examples about how to provide the required information.</del> | |
| − | + | ||
| − | + | =Final Release Day= | |
| + | The R-build is automatically published, so no immediate action is required. | ||
| − | + | ==Update Eclipse Market Entry== | |
| − | + | The Eclipse OCL entry in the Eclipse MarketPlace requires to be updated with the final R-build: | |
| − | = | + | |
| − | + | ||
| − | + | [http://marketplace.eclipse.org/content/eclipse-ocl#.UT2sXhzJT2s Eclipse OCL at Market Place] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | == | + | ==Next Version== |
| − | + | The Eclipse OCL entry in the Eclipse MarketPlace requires to be updated with the final R-build: | |
| + | The project should be moved onto the next release number by editing the many version numbers in MANIFEST.MF, pom.xml, feature.xml. Once this has been debugged using a local Tycho build, the Promoter job can be re-enabled. | ||
| − | + | ==Announcement== | |
| + | Remember to announce the new release in our public [http://www.eclipse.org/forums/index.php?t=thread&frm_id=26 forum]. | ||
Revision as of 07:18, 10 September 2019
In this wiki entry we explain the releng bits that may be done during the quiet week, particularly to the Eclipse OCL project. You may find some general information about the quiet week in the Simultaneous Release Final Daze documentation (Juno, for the time of writing).
The main purpose of the quite week activities is preparing the downloadable zips and the release p2 repository in its final location so that they are properly mirrored across the different mirror servers prior to the final release date, taking into account that the content can't be available for download until that date. The releng tasks to be done are explained in two blocks, the tasks during the Quite Week and those tasks which must be done the Final Release Day.
Contents
Quiet Week
The following are the Eclipse OCL usual releng tasks to be accomplished during what was once the quiet week. Since moving to a four release per year cadence, the quiet week is at best a couple of days. Now that ssh access to build.eclipse.org is more restricted, many of the former quiet week activities are imporactiocal and what is practical should be performed as late as possible in the final SimRel Release Candidate.
Build the final release
Perform an R-build with an alias of the release name. Do this as late as practical before the final SimRel build so that the R-build can be contributed to the SimRel aggregator. Do this as late as practical before the final SimRel build so that the R-build can be contributed to the SimRel aggregator. Once built and promoted, disable the Promoter job to prevent any accidental re-builds until the project moves on to a new version number. Then the Promoter Job can be re-enabled.
Archive old releases
Older download ZIPs are moved to archive:
- Edit the /mdt/downloads/extras-ocl.php file to add the redirections for archived releases
- Copy the releases to archive
cd ~/downloads/modeling/mdt/ocl/downloads/drops mv 5.0.5 /home/data/httpd/archive.eclipse.org/modeling/mdt/ocl/downloads/drops
*Make sure the archive is useable
For each new archived R folder that doesn't have an index.php
cp ../../3.1.0/R201106061427/index.php .
The default Eclipse Foundation archive.eclipse.org 404 page has a "Show Directory Contents." that provides similar/better functionality than the traditional project index.php.
Older P2 repos are moved to archive:
- Copy the repo to archive
cd ~/downloads/modeling/mdt/ocl/updates/releases ant -f /shared/modeling/tools/promotion/manage-composite.xml remove -Dchild.repository=5.0.5 mv 5.0.5 /home/data/httpd/archive.eclipse.org/modeling/mdt/ocl/updates/releases cd /home/data/httpd/archive.eclipse.org/modeling/mdt/ocl/updates/releases ant -f /shared/modeling/tools/promotion/manage-composite.xml add -Dchild.repository=5.0.5
Update the Help Info Center
The Help Info Center is now populated automatically.
With every release a bugzilla is created so that every project can publish where the doc plugin is located in the new release repository. We will usually need to keep an eye to the cross-project-issues mailing list to catch the proper bugzilla up (Following the cross-project dot inbox @at eclipse dot org bugzilla account may also help). In the corresponding Juno release bugzilla 379598 , you may find different examples about how to provide the required information.
Final Release Day
The R-build is automatically published, so no immediate action is required.
Update Eclipse Market Entry
The Eclipse OCL entry in the Eclipse MarketPlace requires to be updated with the final R-build:
Next Version
The Eclipse OCL entry in the Eclipse MarketPlace requires to be updated with the final R-build: The project should be moved onto the next release number by editing the many version numbers in MANIFEST.MF, pom.xml, feature.xml. Once this has been debugged using a local Tycho build, the Promoter job can be re-enabled.
Announcement
Remember to announce the new release in our public forum.