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 "OCL/Dev/Releng/Quiet Week"

< OCL
(New page: 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...)
 
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 quite week in the [[ Juno/Final_Daze | Simultaneous Release Final Daze]] documentation (Juno, for the time of writing).
+
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 [[ Juno/Final_Daze | Simultaneous Release Final Daze]] documentation (Juno, for the time of writing).
  
The following are the Eclipse OCL usal releng tasks to be accomplished during the 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==
 
==Hide the new release in the downloads web page==
Line 14: Line 14:
  
 
==Prepare the downoadable zips area==
 
==Prepare the downoadable zips area==
We usually will want our last published 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 stetps:
+
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) taking into account that a release distribution should start with '''R'''. For instance, for the Juno SR2 release you should do the following:
+
* 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
 
  ~/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 Release Candidate built. We need to manually remove them. The following bash script does it automatically:
+
* 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
 
  #!/bin/bash
 
  # Copyright (c) 2013 Willink Transformations, University of York and others.
 
  # Copyright (c) 2013 Willink Transformations, University of York and others.
Line 43: Line 43:
 
  done
 
  done
  
* Similarly, the md5 files need to be changed:
+
* Similarly, the ''MD5'' files need to be changed:
 
  #!/bin/bash
 
  #!/bin/bash
 
  # Copyright (c) 2013 Willink Transformations, University of York and others.
 
  # Copyright (c) 2013 Willink Transformations, University of York and others.
Line 68: Line 68:
 
   rm $i
 
   rm $i
 
  done
 
  done
* Finally, a small script to verify the MD5 checksum
+
* Finally, a small script to verify the ''MD5'' checksum
 
  #!/bin/bash
 
  #!/bin/bash
 
  # Copyright (c) 2013 Willink Transformations, University of York and others.
 
  # Copyright (c) 2013 Willink Transformations, University of York and others.
Line 82: Line 82:
 
   md5sum -c $i
 
   md5sum -c $i
 
  done
 
  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 ''/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

Revision as of 16:05, 19 February 2013

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 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 they are 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 /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.

Back to the top