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

OCL/Dev/Releng/Quiet Week

< OCL
Revision as of 14:17, 17 June 2013 by Adolfosbh.gmail.com (Talk | contribs) (Prepare the releases p2 repository)

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.

Quiet Week

The following are the Eclipse OCL usual 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:

   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 contains 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:
~/downloads/modeling/mdt/ocl/updates/releases/4.0.2> vi content.jar

Select the content.xml file and look for the RC string using the vi editor search (:/RC). You should find two entries like 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.

note: Remember that the category name pattern is Eclipse OCL-x.y.z
  • The automatically generated p2.mirrorsURL and p2.statsURI repository properties will also have information about the Release Candidate build. Extreme importance has the p2.mirrorsURL, because if the this property refers to an incorrect S-build related URL (whose location may not have the repository content if the milestones repository is cleared), clients won't be able to find the expected content in the mirrored servers provoking errors while trying to install our component.

To fix that, we have access to the artifact.xml (in the same way we did with the content.xml one) and set the URL of the new location of the releases repository, for instance for the Kepler final release:

<property name="p2.statsURI" value="http://download.eclipse.org/stats/modeling/mdt/ocl/updates/releases/4.1.0"/>
<property name="p2.mirrorsURL" value="http://www.eclipse.org/downloads/download.php?file=/modeling/mdt/ocl/updates/releases/4.1.0&format=xml&protocol=http"/>

Update the Help Info Center

With every release a bugzilla is created so that every project can publish where the doc plugi 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

In the final release day, as it's specified by the Simulatenous Release Planning (Kepler by the time of writing), we need to activate our final release to be downloaded from our public downloads area and from our public updates/releases p2 repository. To accomplish that, 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

Update Eclipse Market Entry

The Eclipse OCL entry in the Eclipse MarketPlace requires to be updated:

Eclipse OCL at Market Place

Announcement

Remember to announce the new release in our public forum.

Back to the top