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.
OCL/Dev/Releng/Quiet Week
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 quite 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
Quite Week
The following are the Eclipse OCL usal releng tasks to be accomplished during the quite week.
Hide the new release in the downloads web page
Prior to prepare the downloadable zips of the imminent release in the downloads area, we should ensure that it's not available for downloading. To do that you must follow the following steps:
- Clone the OCL www repository using the following GIT repository URL: ssh://git.eclipse.org/gitroot/www.eclipse.org/modeling/mdt.git
- Import the mdt project into the workspace
- Edit the /mdt/downloads/hidden.txt file and include an entry for the new release to hide, for instance modeling/mdt/4.0.2/R201301281158
note: see the hidden.txt file history to find examples of previous modifications
- Commit and push the change to the remote repository
Prepare the downoadable zips area
We usually will want our last published Release Candidate (RC) to be our final version of the release which will be present in the downloads area. To do that we will have to follow the following steps:
- Copy the last RC (Sxxxxxxxxxxxx for SR0 or Mxxxxxxxxxxxx for SR1 and SR0) from the downloads area taking into account that a release distribution should start with R. For instance, for the Juno SR2 release you should do the following:
~/downloads/modeling/mdt/ocl/downloads/drops/4.0.0> cp -rf M201301281158/ ../4.0.2/R201301281158
- Giving that the zips usually have the RCx suffix of the last built Release Candidate, we need to manually remove them. The following bash script does it automatically:
#!/bin/bash # Copyright (c) 2013 Willink Transformations, University of York and others. # All rights reserved. This program and the accompanying materials # are made available under the terms of the Eclipse Public License v1.0 # which accompanies this distribution, and is available at # http://www.eclipse.org/legal/epl-v10.html # # Contributors: # Adolfo Sanchez-Barbudo Herrera (Univerisity of York) - Initial API and implementation if [ $# -ne 1 ] then echo "usage example: ./renameZips.sh RC1" exit; fi for i in *.zip do newName=${i/$1/} echo "Renaming $i to $newName" mv "$i" "$newName" done
- Similarly, the MD5 files need to be changed:
#!/bin/bash # Copyright (c) 2013 Willink Transformations, University of York and others. # All rights reserved. This program and the accompanying materials # are made available under the terms of the Eclipse Public License v1.0 # which accompanies this distribution, and is available at # http://www.eclipse.org/legal/epl-v10.html # # Contributors: # Adolfo Sanchez-Barbudo Herrera (Univerisity of York) - Initial API and implementation if [ $# -ne 1 ] then echo "usage example: ./renameMD5.sh RC1" exit; fi for i in *.md5 do iContent=`cat $i` newName=${i/$1/} newContent=${iContent/$1/} echo "Introducing $newContent into $newName" echo "$newContent" > "$newName" rm $i done
- Finally, a small script to verify the MD5 checksum
#!/bin/bash # Copyright (c) 2013 Willink Transformations, University of York and others. # All rights reserved. This program and the accompanying materials # are made available under the terms of the Eclipse Public License v1.0 # which accompanies this distribution, and is available at # http://www.eclipse.org/legal/epl-v10.html # # Contributors: # Adolfo Sanchez-Barbudo Herrera (Univerisity of York) - Initial API and implementation for i in *.md5 do md5sum -c $i done
Prepare the releases p2 repository
Likewise, the p2 repository corresponding to the new release needs to be in place to further be composed by the updates/releases composite repo. To do that we will have to follow the following steps:
- Copy the last tools p2 repository contributed to the simultaneous release train (the last milestones/x.y.z/tools repository for SR0 or the last ' maintenance/x.y.z/tools repository for SR1 and SR2) into the corresponding updates/releases/x.y.z repository.
note: Look at updates/releases repository content and follow the layout.
- The contributed repository usually specifies a category name for the repository content which correspond to the alias of the build, hence, some undesirable RCx information. To remove that simply edit the content.jar/content.xml file and look for the specific RCx string. For the Juno SR2 p2 repository you should find the following:
<property name='org.eclipse.equinox.p2.name' value='OCL-4.0.2RC2'/> <property name='org.eclipse.equinox.p2.description' value='Eclipse OCL-4.0.2RC2 features.'/>
Simply edit the values and remove the RC2 bits.
- Finally, verify that the content is properly accessible by an Eclipse installation. You could check that by trying to install new software and using the corresponding new releases repository. For the Juno SR2 release you'd use the following URL: http://download.eclipse.org/modeling/mdt/ocl/updates/releases/4.0.2
Final Release Day
In the final release day, as it's specified by the Simulatenous Release Planning (Kepler by the tome of writing), we need to activate our final release to be downloaded from our public downloads area and from our public releases p2 repository. To accomplish that you the following tasks need to be undertaken.
Show the new release in the downloads web page
Basically, we have to follow similar steps to those we did to hide the release. Providing you have previously imported the mdt project from the cloned the OCL www GIT repository, the steps to do are the following:
- Edit the /mdt/downloads/hidden.txt file and remove the entry for the new release to make it visible.
- Commit and push the change to the remote repository
Make the new release p2 repository be available
During the quite week, we prepared the p2 repository under the updates/releases folder. However the new release repository needs to be activated by including it as a children of our public updates/releases (composite) repository. To do that we will simply have to use the Manage Composite Utility. For instance for the Juno SR2 release:
~/downloads/modeling/mdt/ocl/updates/releases> ant -f /shared/modeling/tools/promotion/manage-composite.xml add -Dchild.repository=4.0.2