Difference: PrepareProjectRelease (1 vs. 48)

Revision 482016-08-08 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

Changed:
<
<
This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
>
>
BEWARE: the procedures described here apply only to projects maintained in SVN. If you wish to release a project maintained in Git (i.e. the vast majority of LHCb software), a different procedure applies
 
Changed:
<
<
BEWARE: these procedures apply only to projects tagged in SVN. If you wish to release a project only tagged in Git, a different procedure applies

Repeat: all software release managers should be members of this group lhcb-release-managers

>
>
This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
 

Revision 472016-08-08 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Changed:
<
<
BEWARE: these procedures apply only to projects tagged in SVN. If you wish to release a project only tagged in Git, a different procedure applies, [WIP] to be documented....
>
>
BEWARE: these procedures apply only to projects tagged in SVN. If you wish to release a project only tagged in Git, a different procedure applies
  Repeat: all software release managers should be members of this group lhcb-release-managers

Revision 462016-06-03 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

Changed:
<
<
This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
>
>
This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group

BEWARE: these procedures apply only to projects tagged in SVN. If you wish to release a project only tagged in Git, a different procedure applies, [WIP] to be documented....

  Repeat: all software release managers should be members of this group lhcb-release-managers

Revision 452014-12-15 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 82 to 82
 

Tagging

The project has to be correctly tagged in order to be ready for release.
Changed:
<
<
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package the files project.cmt, CMakeLists.txt, toolchain.cmake, have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
>
>
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package the files project.cmt, CMakeLists.txt, have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
  1: Update the project dependencies and tag the <PROJECT> package
Line: 106 to 106
  (b) Checkout the project trunk directory (non-recursively) and the contained cmt directory
Changed:
<
<
(c) make any needed modifications to the files project.cmt, CMakeLists.txt and toolchain.cmake.
>
>
(c) make any needed modifications to the files project.cmt and CMakeLists.txt.
  (d) Then select the modified files (CTRL+left click) then right click on the selection, and go to Team->Commit, to commit them to the trunk.
Line: 192 to 192
 

Tagging

The project has to be correctly tagged in order to be ready for release.
Changed:
<
<
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package the files project.cmt, CMakeLists.txt, toolchain.cmake, have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
>
>
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package the files project.cmt, CMakeLists.txt, have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
  Note that the procedure applies to projects. For data packages, it's enough to just tag the package, as in the last step.
Line: 202 to 202
 
getpack -P -H LBCOM HEAD
cd LBCOM/LBCOM_HEAD
Changed:
<
<
    • edit cmt/project.cmt, CMakeLists.txt and toolchain.cmake to update the dependencies of the project
>
>
    • edit cmt/project.cmt and CMakeLists.txt to update the dependencies of the project
 
    • commit and tag with the new version number (for example v99r11):

Changed:
<
<
svn commit -m v99r11 cmt CMakeLists.txt toolchain.cmake
>
>
svn commit -m v99r11 cmt CMakeLists.txt
 tag_package -P Lbcom v99r11
  1. Tag all the packages that are updated for the release. The packages to be updated should be documented in the LHCbTagCollector.
Line: 345 to 345
  Tip, idea It is usually useful to add a -d option to all the command lines above to see what exactly the tool is performing. To see the command-line tool help issue ariadne add -h.
Changed:
<
<

Mandatory: Request @ JIRA

If the nightly tests are successful, you can ask for a release. The release request has to be made in The JIRA project for deployment

The previous task tracker in Savannah is still accessible here.

>
>

Mandatory: Trigger the release build and request deployment

Once you are satisfied that the release is ready, follow the instructions at ProjectRelease#For_Release_Managers to trigger a release build and request its deployment.
 

Clean up the tag collector

Once you have made the release request, you should "hide" the project from the tag collector, by clicking on the red cross to the right of the project heading and answering OK to the following questions. Before you do so, check that no-one has added new package revisions after you tagged the project. If any were added, move them to a newer version of the project, using the "Edit" button next to the package revision entry.

Revision 442014-10-06 - BenjaminCouturier

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 308 to 308
 

This URL can be inserted in the usual release.notes to reduce the amount of writing, and speed up the release procedure for you.

Changed:
<
<
It has the added advantages that the changesets in SVN, and savannah bug reports are linked directly, so persons looking through the release.notes can get a very clear picture of what has happened.
>
>
It has the added advantages that the changesets in SVN, and bug reports are linked directly, so persons looking through the release.notes can get a very clear picture of what has happened.
 
  • In the case you have used the tag collector to collect and tag all included packages, you can place the fixed url for the changes into the release notes, rather than writing them yourself.
  • In the case you haven't used the tag collector, or not all the changes are in the tag collector, then you are at liberty to write your own subsequent comments.
Line: 345 to 345
  Tip, idea It is usually useful to add a -d option to all the command lines above to see what exactly the tool is performing. To see the command-line tool help issue ariadne add -h.
Changed:
<
<

Mandatory: Request @ Savannah

If the nightly tests are successful, you can ask for a release. The release request has to be made in the task tracker of the LHCb Deployment Savannah project.
>
>

Mandatory: Request @ JIRA

If the nightly tests are successful, you can ask for a release. The release request has to be made in The JIRA project for deployment

The previous task tracker in Savannah is still accessible here.

 

Clean up the tag collector

Once you have made the release request, you should "hide" the project from the tag collector, by clicking on the red cross to the right of the project heading and answering OK to the following questions. Before you do so, check that no-one has added new package revisions after you tagged the project. If any were added, move them to a newer version of the project, using the "Edit" button next to the package revision entry.

Revision 432014-05-29 - IllyaShapoval

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 341 to 341
  tag:PARTITION:TAGNAME reco_type:NAME sim_type:NAME
Changed:
<
<
detector_type:NAME platform:NAME
>
>
detector_type:NAME
  Tip, idea It is usually useful to add a -d option to all the command lines above to see what exactly the tool is performing. To see the command-line tool help issue ariadne add -h.

Revision 422014-05-20 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

Changed:
<
<
This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
>
>
This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
  Repeat: all software release managers should be members of this group lhcb-release-managers

Revision 412014-04-30 - IllyaShapoval

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 315 to 315
 
  • In either case there will be some release notes you'll want to add by hand anyway, to describe the purpose of the release and highlight major changes.

Add compatibility information to Ariadne

Changed:
<
<
This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. The procedure has to be done from LXPLUS, or any other SLC machine with Kerberized CERN login and 'cern-get-sso-cookie' package installed.
>
>
This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. The procedure has to be done from LXPLUS, or any SLC machine with Kerberized CERN login and 'cern-get-sso-cookie' package installed (note that access to Ariadne from SLC5 and earlier is not supported any more).
 Essentially, what has to be done in this step is insertion into the Ariadne system of a new application version and of all its relationships to other Ariadne metadata entities that it has to have.

Below the most frequent use cases are listed:

Revision 402014-04-23 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 39 to 39
 
svnCheckTags Check that the packages and tags requested in a given requirements file or project.cmt exist. Can also compare the contents with the trunk. svnCheckTags Rec v12r0 --diffs
svnDiffTags Compare the contents of two tagged versions of a package or project and its dependent packages svnDiffTags Rec v11r0 v12r0
cmpPackageWithTrunk compare the content of a checked-out (and modified) version of the software with the trunk cmpPackageWithTrunk --all
Added:
>
>
getNightlyRefs copy any new reference files from a specific nightly slot to a local checkout so that you don't need to re-run the tests yourself. getNightlyRefs lhcb-prerelease
 

Test Driven Development

Revision 392014-04-22 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 295 to 295
  N.B. If your package, or its tests, depend on a data package, check that the nightlies are picking up the latest version (or even the SVN HEAD if needed). See here how data packages are made available in the nightlies
Changed:
<
<
Often the nightly tests will fail in trivial ways which are cured by simply updating the test references. You can use the getNightlyRefs script from Lbscripts to copy the references to some local checkout without needing to re-run the tests yourself using rsynch to add the .new files to some local checkout. getNightlyRefs has its own help, and dies not work outside the CERN firewall. Having carefully checked and updated references, you can retag the affected packages before the release request.
>
>
Often the nightly tests will fail in trivial ways which are cured by simply updating the test references. You can use the getNightlyRefs script from Lbscripts to copy the references to some local checkout without needing to re-run the tests yourself using rsynch to add the .new files to some local checkout. getNightlyRefs has its own help, and does not work outside the CERN firewall. Having carefully checked and updated references, you can retag the affected packages before the release request.
 

Writing the release notes

Revision 382014-04-22 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 295 to 295
  N.B. If your package, or its tests, depend on a data package, check that the nightlies are picking up the latest version (or even the SVN HEAD if needed). See here how data packages are made available in the nightlies
Added:
>
>
Often the nightly tests will fail in trivial ways which are cured by simply updating the test references. You can use the getNightlyRefs script from Lbscripts to copy the references to some local checkout without needing to re-run the tests yourself using rsynch to add the .new files to some local checkout. getNightlyRefs has its own help, and dies not work outside the CERN firewall. Having carefully checked and updated references, you can retag the affected packages before the release request.
 

Writing the release notes

The release notes for different projects follow different models and have different levels of verbosity.

Revision 372013-12-16 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 311 to 311
 
  • In the case you haven't used the tag collector, or not all the changes are in the tag collector, then you are at liberty to write your own subsequent comments.
  • In either case there will be some release notes you'll want to add by hand anyway, to describe the purpose of the release and highlight major changes.
Changed:
<
<

Add compatibility information to Ariadne

>
>

Add compatibility information to Ariadne

 This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. The procedure has to be done from LXPLUS, or any other SLC machine with Kerberized CERN login and 'cern-get-sso-cookie' package installed. Essentially, what has to be done in this step is insertion into the Ariadne system of a new application version and of all its relationships to other Ariadne metadata entities that it has to have.

Revision 362013-11-22 - IllyaShapoval

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 312 to 312
 
  • In either case there will be some release notes you'll want to add by hand anyway, to describe the purpose of the release and highlight major changes.

Add compatibility information to Ariadne

Changed:
<
<
This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. Currently, the procedure has to be done from lxbuild119.
>
>
This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. The procedure has to be done from LXPLUS, or any other SLC machine with Kerberized CERN login and 'cern-get-sso-cookie' package installed.
 Essentially, what has to be done in this step is insertion into the Ariadne system of a new application version and of all its relationships to other Ariadne metadata entities that it has to have.

Below the most frequent use cases are listed:

Revision 352013-11-08 - IllyaShapoval

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 320 to 320
 
  1. Adding an application version WITHOUT compatibility relationships (i.e, incompatible with everything):
    This covers the simplest case of adding a new application version, which is incompatible with everything known by that time (see the flavor list of tracked entities at the bottom of the section). See below the command line on an example of Brunel vXrY:

Changed:
<
<
ariadne_add application:Brunel:vXrY
>
>
ariadne add application:Brunel:vXrY
  The latter command line will add a standalone 'application' node to the knowledge graph of the Ariadne system which, in essence, is not related in any way to other Ariadne nodes. This, though, doesn't prevent to add any relationships to it later on.
  1. Adding an application version WITH compatibility relationships, IDENTICAL to those of another application version:
    If a new application version has to inherit all relationships from an existent application version (which is what is wanted in most of the cases) the following command line will do the job:

Changed:
<
<
ariadne_add application:Brunel:vXrY =application:Brunel:vXrZ
>
>
ariadne add application:Brunel:vXrY =application:Brunel:vXrZ
  The instruction in the second argument, uses the '=' operator to specify the node where relationships have to be cloned from.
  1. Adding an application version with NEW set of compatibility relationships:
    This is the most non-trivial use case. Let's say one needs to clone all relationships from an existent node, then add relationship to, e.g., Reco20 reco type, and remove another relationship to 2012 detector type. To accomplish this two extra instructions, using '+' and '-' operators, have to be given:

Changed:
<
<
ariadne_add application:Brunel:vXrY =application:Brunel:vXrZ +reco_type:Reco20 -detector_type:2012
>
>
ariadne add application:Brunel:vXrY =application:Brunel:vXrZ +reco_type:Reco20 -detector_type:2012
  In all the above mentioned examples the following metadata entities may be specified:

Line: 340 to 340
  sim_type:NAME detector_type:NAME platform:NAME
Changed:
<
<
Tip, idea It is usually useful to add a -d option to all the command lines above to see what exactly the tool is performing. To see the command-line tool help issue ariadne_add -h.
>
>
Tip, idea It is usually useful to add a -d option to all the command lines above to see what exactly the tool is performing. To see the command-line tool help issue ariadne add -h.
 

Mandatory: Request @ Savannah

Revision 342013-09-20 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 41 to 41
 
cmpPackageWithTrunk compare the content of a checked-out (and modified) version of the software with the trunk cmpPackageWithTrunk --all
Added:
>
>

Test Driven Development

Don't forget about testing any changes which go into production software, we try and encourage TestDrivenDevelopment, where behavioural tests are enshrined in our QM-Test framework.

 

Option 1: Tag Collector and Eclipse

The Tag Collector has a lot of release-manager helper features.

Revision 332013-08-01 - ChristopherRJones

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 124 to 123
 
Changed:
<
<
>
>
 Description:
Changed:
<
<
>
>
  Video Example:
Line: 147 to 146
 
Changed:
<
<
>
>
 
Line: 156 to 155
 3:Update the <Project>Sys package
Changed:
<
<
>
>
 Description:
Changed:
<
<
>
>
  Video Example:
Line: 179 to 178
 
Changed:
<
<
>
>
 

Revision 322013-07-25 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 309 to 309
 
  • In either case there will be some release notes you'll want to add by hand anyway, to describe the purpose of the release and highlight major changes.

Add compatibility information to Ariadne

Changed:
<
<
This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. Currently, the procedure has to be done from lxbuild119.
>
>
This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. Currently, the procedure has to be done from lxbuild119.
 Essentially, what has to be done in this step is insertion into the Ariadne system of a new application version and of all its relationships to other Ariadne metadata entities that it has to have.

Below the most frequent use cases are listed:

Revision 312013-07-09 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 290 to 290
 
Added:
>
>
N.B. If your package, or its tests, depend on a data package, check that the nightlies are picking up the latest version (or even the SVN HEAD if needed). See here how data packages are made available in the nightlies
 

Writing the release notes

The release notes for different projects follow different models and have different levels of verbosity.

Revision 302013-07-03 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 190 to 190
 The project has to be correctly tagged in order to be ready for release. A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package the files project.cmt, CMakeLists.txt, toolchain.cmake, have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
Changed:
<
<
The following is the recommended procedure for tagging the packages and project. Note that the procedure applies to projects. For data packages, it's enough to just tag the package, as in the last step.
>
>
Note that the procedure applies to projects. For data packages, it's enough to just tag the package, as in the last step.
 
  1. Go to a working directory with lots of quota (typically a directory on a local disk of your machine)

  2. Update the project dependencies and tag the <PROJECT> package
Line: 231 to 231
 tag_package LbcomSys

Mandatory: Checks prior to release

Added:
>
>
Description: Video Example:
 
  1. Check that the whole project is correctly tagged
Changed:
<
<
    • It is now possible to do this directly through SVN:
>
>
    • It is now possible to do this directly through SVN:
 
svnCheckTags Lbcom v99r11
Changed:
<
<
    • This will print warnings and errors if tags are missing.
    • In case of missing or incorrect tags, you may have to retag the Sys package

>
>
    • This will print warnings and errors if tags are missing.
    • In case of missing or incorrect tags, you may have to retag the Sys package

 
  1. Check that nothing has been missed from the release
    svnCheckTags Lbcom v99r11 --diffs
Changed:
<
<
This gives you any files that are in the trunk of SVN but not included in the release tag. This is either because you made a mistake in the tagging above, or because the changes were not included in the tag collector, either on purpose or by accident. Usually this is avoided by checking the LostTags of the TagCollector before this stage. In the latter case decide if the changes should anyway be included - either unilaterally or in consultation with the author of the changes. You may have to retag.
>
>
This gives you any files that are in the trunk of SVN but not included in the release tag. This is either because you made a mistake in the tagging above, or because the changes were not included in the tag collector, either on purpose or by accident. Usually this is avoided by checking the LostTags of the TagCollector before this stage. In the latter case decide if the changes should anyway be included - either unilaterally or in consultation with the author of the changes. You may have to retag.

 

Add a new version of the project to the tag collector

Line: 250 to 266
 

Mandatory: Nightly test of the software

The tagged software should be built and tested at least once in the LHCbNightlies build system.
Changed:
<
<
Go to the nightlies page, and spawn the configuration editor to add your project into the lhcb-prerelease slot. Usually this means updating the existing entry by double-clicking the version. If the "Disabled" flag is set to true, you should change it to false, so that the new project gets built.
>
>
Description: Video Example:
(a) Go to the nightlies page

(b) spawn the configuration editor

(c) Add your project into the lhcb-prerelease slot. Usually this means updating the existing entry by double-clicking the version. If the "Disabled" flag is set to true, you should change it to false, so that the new project gets built.

 
Changed:
<
<
Nightly Editor
>
>
 

Writing the release notes

Revision 292013-07-03 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 51 to 51
 
Changed:
<
<

Checks before tagging

>
>

Checks before tagging (lost tags)

 
Changed:
<
<
You can check if anyone has made a change which has not appeared on the tag collector. Login to the tag collector and go to Lost Tags. Type and choose from the auto fill the name of the package. If someone has made a modification, but not put it on the tag collector it will appear in the list of "Missing Tags".

You can then select the radio button to see what the revisions were which were not requested in the tag collector, and then either add it to the tag collector, or more likely, contact the author to request clarification.

Lost Tags

>
>
Description: Video Example:

You can check if anyone has made a change which has not appeared on the tag collector. Login to the tag collector and go to Lost Tags. Type and choose from the auto fill the name of the package. If someone has made a modification, but not put it on the tag collector it will appear in the list of "Missing Tags".

You can then select the radio button to see what the revisions were which were not requested in the tag collector, and then either add it to the tag collector, or more likely, contact the author to request clarification. The example on the right is for HLT and Moore v20r2.

 

Tagging

The project has to be correctly tagged in order to be ready for release. A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package the files project.cmt, CMakeLists.txt, toolchain.cmake, have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
Changed:
<
<
  • Update the project dependencies and tag the <PROJECT> package
>
>
1: Update the project dependencies and tag the <PROJECT> package

Description: Video Example:

Firstly, you need to make the project structure inside Eclipse. The example video on the right does these steps for HLT, in the old cmt-style tagging.

(a) Switch to the SVN view and navigate down to the project directory.

(b) Checkout the project trunk directory (non-recursively) and the contained cmt directory

(c) make any needed modifications to the files project.cmt, CMakeLists.txt and toolchain.cmake.

(d) Then select the modified files (CTRL+left click) then right click on the selection, and go to Team->Commit, to commit them to the trunk.

(e) Copy the cmt directory from the trunk, then. Navigate to the tags/PROJECT directory, and make a new sub directory for LBCOM_v99r11.

 
Added:
>
>
(f) Then paste the cmt folder into this directory.
 
Changed:
<
<
Firstly, you need to make the project structure inside Eclipse. Switch to the SVN view and navigate down to the project directory. Checkout the project trunk directory (non-recursively) and the contained cmt directory and make any needed modifications to the files project.cmt, CMakeLists.txt and toolchain.cmake.
>
>
(g) Repeat the copy&paste steps for all the files in the project directory (e.g. CMakeLists.txt, Makefile,...) and for the directory cmake.
 
Changed:
<
<
Eclipse Checkout
>
>
 
Changed:
<
<
Then select the modified files (CTRL+left click) then right click on the selection, and go to Team->Commit, to commit them to the trunk.
>
>
 
Changed:
<
<
Eclipse Commit
>
>
2: Tag all the packages that are updated for the release. The packages to be updated should be documented in the LHCbTagCollector.
 
Changed:
<
<
Copy the cmt directory from the trunk, then. Navigate to the tags/LBCOM directory, and make a new sub directory for LBCOM_v99r11. Then paste the cmt folder into this directory. Repeat the copy&paste steps for all the files in the project directory (e.g. CMakeLists.txt, Makefile,...) and for the directory cmake (Note: this step is automated with the command line tool tag_package).
>
>
Description: Video Example:
Next you should tag all the packages using the TagPackage page of the tag collector. For each modified package on the tag collector, fill out this form. The example on the right is given for tagging an HLT release. Note that it takes only a few of minutes to etag an entire project this way.It autocompletes, so
 
Changed:
<
<
Eclipse Tag
>
>
(a) first select the package name, then the project will be suggested.
 
Changed:
<
<
  • Tag all the packages that are updated for the release. The packages to be updated should be documented in the LHCbTagCollector.
>
>
(b) Click in the version box and it will be filled for you, the requirements file and release notes will be downloaded from SVN.
 
Changed:
<
<
Next you should tag all the packages using the TagPackage page of the tag collector. For each modified package on the tag collector, fill out this form. It autocompletes, so first select the package name, then the project will be suggested. Click in the version box and it will be filled for you, the requirements file and release notes will be downloaded from SVN.
>
>
(c) You can freely modify the requirements and release notes, are free to choose the name of the next version,
 
Changed:
<
<
You can freely modify the requirements and release notes, are free to choose the name of the next version, and can insert the tagging comment automatically by clicking the button. Once you are satisfied, choose submit to commit your changes to SVN and tag the package with the version you have given.
>
>
(d) Insert the tagging comment automatically by clicking the button.
 
Changed:
<
<
TagPackage
>
>
(e) Once you are satisfied, choose submit to commit your changes to SVN and tag the package with the version you have given.
 
Changed:
<
<
  • Update the <Project>Sys package
>
>
 
Deleted:
<
<
Then there is only one package left to modify, the Sys package, in this case you want to create LbcomSys v99r11, which can be easily achieved by having the Tag Collector main page open in one window, and the Tag Package script open in another.
 
Changed:
<
<
Edit the requirements file and release notes to give all the changes and new tags you have incorporated in this version, then click submit, and that's you done.
>
>
3:Update the <Project>Sys package
Description: Video Example:
Then there is only one package left to modify, the Sys package, in this case you want to create e.g: "LbcomSys v99r11", which can be easily achieved by having the Tag Collector main page open in one window, and the Tag Package script open in another.

(a) Display the project you are interested in in one window

(b) Open the tag package for the sys package in another window

(c) Update the requirements file with the tags you just made in the above step.

(d) Edit the release notes to give all the changes and new tags you have incorporated in this version

(e) click submit, and that's you done.

 

Option 2: Command-line based

Line: 146 to 236
 
svnCheckTags Lbcom v99r11
    • This will print warnings and errors if tags are missing.
    • In case of missing or incorrect tags, you may have to retag the Sys package

Added:
>
>
 
  1. Check that nothing has been missed from the release
    svnCheckTags Lbcom v99r11 --diffs
    This gives you any files that are in the trunk of SVN but not included in the release tag. This is either because you made a mistake in the tagging above, or because the changes were not included in the tag collector, either on purpose or by accident. Usually this is avoided by checking the LostTags of the TagCollector before this stage. In the latter case decide if the changes should anyway be included - either unilaterally or in consultation with the author of the changes. You may have to retag.
Changed:
<
<
  1. Check that getpack has no problems with the packages
    • That the tags exist on svn usually proves everything is fine, but to be doubly sure you can check that getpack will find all the packages
    • go somewhere with a lot of free disc space
      getpack --project --branch -r LBCOM v99r11
    • if the getpack works, then you are ready for the release.
>
>
 

Add a new version of the project to the tag collector

Once you have tagged the project, you should avoid having new package revisions added to the project in the tag collector. Create a "New Project" where people can add new revisions, and edit the description of the project to be released to say that the project is tagged and frozen and no new package revisions should be added

Revision 282013-07-01 - IllyaShapoval

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 184 to 184
 
  • In either case there will be some release notes you'll want to add by hand anyway, to describe the purpose of the release and highlight major changes.

Add compatibility information to Ariadne

Changed:
<
<
This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne.
>
>
This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. Currently, the procedure has to be done from lxbuild119.
 Essentially, what has to be done in this step is insertion into the Ariadne system of a new application version and of all its relationships to other Ariadne metadata entities that it has to have.

Below the most frequent use cases are listed:

Revision 272013-07-01 - IllyaShapoval

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 183 to 183
 
  • In the case you haven't used the tag collector, or not all the changes are in the tag collector, then you are at liberty to write your own subsequent comments.
  • In either case there will be some release notes you'll want to add by hand anyway, to describe the purpose of the release and highlight major changes.
Changed:
<
<

Add compatibility information to Ariadne (IGNORE this step for now, the system is not yet in production)

>
>

Add compatibility information to Ariadne

 This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. Essentially, what has to be done in this step is insertion into the Ariadne system of a new application version and of all its relationships to other Ariadne metadata entities that it has to have.

Revision 262013-06-24 - IllyaShapoval

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 192 to 192
 
  1. Adding an application version WITHOUT compatibility relationships (i.e, incompatible with everything):
    This covers the simplest case of adding a new application version, which is incompatible with everything known by that time (see the flavor list of tracked entities at the bottom of the section). See below the command line on an example of Brunel vXrY:

Changed:
<
<
ariadne_add.py application:Brunel:vXrY
>
>
ariadne_add application:Brunel:vXrY
  The latter command line will add a standalone 'application' node to the knowledge graph of the Ariadne system which, in essence, is not related in any way to other Ariadne nodes. This, though, doesn't prevent to add any relationships to it later on.
  1. Adding an application version WITH compatibility relationships, IDENTICAL to those of another application version:
    If a new application version has to inherit all relationships from an existent application version (which is what is wanted in most of the cases) the following command line will do the job:

Changed:
<
<
ariadne_add.py application:Brunel:vXrY =application:Brunel:vXrZ
>
>
ariadne_add application:Brunel:vXrY =application:Brunel:vXrZ
  The instruction in the second argument, uses the '=' operator to specify the node where relationships have to be cloned from.
  1. Adding an application version with NEW set of compatibility relationships:
    This is the most non-trivial use case. Let's say one needs to clone all relationships from an existent node, then add relationship to, e.g., Reco20 reco type, and remove another relationship to 2012 detector type. To accomplish this two extra instructions, using '+' and '-' operators, have to be given:

Changed:
<
<
ariadne_add.py application:Brunel:vXrY =application:Brunel:vXrZ +reco_type:Reco20 -detector_type:2012
>
>
ariadne_add application:Brunel:vXrY =application:Brunel:vXrZ +reco_type:Reco20 -detector_type:2012
  In all the above mentioned examples the following metadata entities may be specified:

Line: 212 to 212
  sim_type:NAME detector_type:NAME platform:NAME
Changed:
<
<
Tip, idea It is usually useful to add a -d option to all the command lines above to see what exactly the tool is performing. To see the command-line tool help issue ariadne_add.py -h.
>
>
Tip, idea It is usually useful to add a -d option to all the command lines above to see what exactly the tool is performing. To see the command-line tool help issue ariadne_add -h.
 

Mandatory: Request @ Savannah

Revision 252013-06-11 - IllyaShapoval

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 183 to 183
 
  • In the case you haven't used the tag collector, or not all the changes are in the tag collector, then you are at liberty to write your own subsequent comments.
  • In either case there will be some release notes you'll want to add by hand anyway, to describe the purpose of the release and highlight major changes.
Added:
>
>

Add compatibility information to Ariadne (IGNORE this step for now, the system is not yet in production)

This step applies only to the following projects: Gauss, Boole, Moore, Brunel, DaVinci. All the rest are not (yet) tracked by Ariadne. Essentially, what has to be done in this step is insertion into the Ariadne system of a new application version and of all its relationships to other Ariadne metadata entities that it has to have.

Below the most frequent use cases are listed:

  1. Adding an application version WITHOUT compatibility relationships (i.e, incompatible with everything):
    This covers the simplest case of adding a new application version, which is incompatible with everything known by that time (see the flavor list of tracked entities at the bottom of the section). See below the command line on an example of Brunel vXrY:
          ariadne_add.py application:Brunel:vXrY
    The latter command line will add a standalone 'application' node to the knowledge graph of the Ariadne system which, in essence, is not related in any way to other Ariadne nodes. This, though, doesn't prevent to add any relationships to it later on.
  2. Adding an application version WITH compatibility relationships, IDENTICAL to those of another application version:
    If a new application version has to inherit all relationships from an existent application version (which is what is wanted in most of the cases) the following command line will do the job:
          ariadne_add.py application:Brunel:vXrY =application:Brunel:vXrZ
    The instruction in the second argument, uses the '=' operator to specify the node where relationships have to be cloned from.
  3. Adding an application version with NEW set of compatibility relationships:
    This is the most non-trivial use case. Let's say one needs to clone all relationships from an existent node, then add relationship to, e.g., Reco20 reco type, and remove another relationship to 2012 detector type. To accomplish this two extra instructions, using '+' and '-' operators, have to be given:
          ariadne_add.py application:Brunel:vXrY =application:Brunel:vXrZ +reco_type:Reco20 -detector_type:2012

In all the above mentioned examples the following metadata entities may be specified:

      application:NAME:VERSION
      tag:PARTITION:TAGNAME
      reco_type:NAME
      sim_type:NAME
      detector_type:NAME
      platform:NAME
Tip, idea It is usually useful to add a -d option to all the command lines above to see what exactly the tool is performing. To see the command-line tool help issue ariadne_add.py -h.
 

Mandatory: Request @ Savannah

If the nightly tests are successful, you can ask for a release. The release request has to be made in the task tracker of the LHCb Deployment Savannah project.

Revision 242013-04-23 - LaurenceCarson

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 163 to 163
 

Mandatory: Nightly test of the software

The tagged software should be built and tested at least once in the LHCbNightlies build system.
Changed:
<
<
Go to the nightlies page, and spawn the configuration editor to add your project into the lhcb-prerelease slot. Usually this means updating the existing entry by double-clicking the version.
>
>
Go to the nightlies page, and spawn the configuration editor to add your project into the lhcb-prerelease slot. Usually this means updating the existing entry by double-clicking the version. If the "Disabled" flag is set to true, you should change it to false, so that the new project gets built.
  Nightly Editor

Revision 232012-12-14 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 257 to 257
  Then tag
Changed:
<
<
tag_package LHCbSys -B v34r3b
>
>
tag_package LHCbSys -B v34r3b v34r3p1
 

Test

Revision 222012-12-02 - ChristopherRJones

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 153 to 153
 
    • That the tags exist on svn usually proves everything is fine, but to be doubly sure you can check that getpack will find all the packages
    • go somewhere with a lot of free disc space

Changed:
<
<
getpack --project -r LBCOM v99r11
>
>
getpack --project --branch -r LBCOM v99r11
 
    • if the getpack works, then you are ready for the release.

Revision 212012-11-22 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 61 to 61
 

Tagging

The project has to be correctly tagged in order to be ready for release.
Changed:
<
<
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package and project.cmt file have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
>
>
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package the files project.cmt, CMakeLists.txt, toolchain.cmake, have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
 
  • Update the project dependencies and tag the <PROJECT> package
Changed:
<
<
Firstly, you need to make the project structure inside Eclipse. Switch to the SVN view and navigate down to the project directory. Checkout the cmt directory any make any needed modifications to the project.cmt file.
>
>
Firstly, you need to make the project structure inside Eclipse. Switch to the SVN view and navigate down to the project directory. Checkout the project trunk directory (non-recursively) and the contained cmt directory and make any needed modifications to the files project.cmt, CMakeLists.txt and toolchain.cmake.
  Eclipse Checkout
Changed:
<
<
Then right click on the modified file, and go to Team->Commit, to commit it to the trunk.
>
>
Then select the modified files (CTRL+left click) then right click on the selection, and go to Team->Commit, to commit them to the trunk.
  Eclipse Commit
Changed:
<
<
Copy the cmt directory from the trunk, then. Navigate to the tags/LBCOM directory, and make a new sub directory for LBCOM_v99r11. Then paste the cmt folder into this directory. Repeat the copy&paste steps for all the files in the project directory (e.g. CMakeLists.txt, Makefile,...) and for the directory cmake (Note: this step is easier with the command line).
>
>
Copy the cmt directory from the trunk, then. Navigate to the tags/LBCOM directory, and make a new sub directory for LBCOM_v99r11. Then paste the cmt folder into this directory. Repeat the copy&paste steps for all the files in the project directory (e.g. CMakeLists.txt, Makefile,...) and for the directory cmake (Note: this step is automated with the command line tool tag_package).
  Eclipse Tag
Line: 90 to 90
 
  • Update the <Project>Sys package
Changed:
<
<
Then there is only one package left to modify, the Sys package, in this case you want to create LbcomSys v99r11, which can be easily acheived by having the Tag Collector main page open in one window, and the Tag Package script open in another.
>
>
Then there is only one package left to modify, the Sys package, in this case you want to create LbcomSys v99r11, which can be easily achieved by having the Tag Collector main page open in one window, and the Tag Package script open in another.
 
Changed:
<
<
Edit the requirements file and release notes to give all the changes and new tags you have incorporated in this verison, then click submit, and that's you done.
>
>
Edit the requirements file and release notes to give all the changes and new tags you have incorporated in this version, then click submit, and that's you done.
 

Option 2: Command-line based

Tagging

The project has to be correctly tagged in order to be ready for release.
Changed:
<
<
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package and project.cmt file have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
>
>
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package the files project.cmt, CMakeLists.txt, toolchain.cmake, have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
  The following is the recommended procedure for tagging the packages and project. Note that the procedure applies to projects. For data packages, it's enough to just tag the package, as in the last step.
Line: 108 to 108
 
getpack -P -H LBCOM HEAD
cd LBCOM/LBCOM_HEAD
Changed:
<
<
    • edit cmt/project.cmt to update the dependencies of the project
>
>
    • edit cmt/project.cmt, CMakeLists.txt and toolchain.cmake to update the dependencies of the project
 
    • commit and tag with the new version number (for example v99r11):

Changed:
<
<
cd cmt svn commit -m v99r11 cd ..
>
>
svn commit -m v99r11 cmt CMakeLists.txt toolchain.cmake
 tag_package -P Lbcom v99r11
  1. Tag all the packages that are updated for the release. The packages to be updated should be documented in the LHCbTagCollector.
Line: 124 to 122
 
    • If the Revision corresponds to the revision given in the tag collector, all is well, the package trunk corresponds to the version that should be released. If the Revision is different, you have to decide whether you want to include them in the release - either unilaterally or in consultation with the author of the changes. You can check the differences with svn diff -r <someRevision>, where <someRevision> is the revision with which you want to compare, for example the revision given in the tag collector. If all is well,
    • In doc/release.notes, add the line with release version number and date
      • If already added by the package manager, check that the version number is correct, and that they haven't moved the line from a previous release - yes I happens!)
Changed:
<
<
    • Check that cmt/requirements contains the new version number
>
>
    • Check that cmt/requirements and CMakeLists.txt contain the new version number
 
      • If not, update it
    • commit and tag with the new version number:
      svn commit -m <theNewOfficialTag>
Changed:
<
<
tag_package Hat/Package
>
>
tag_package Hat/Package (the tag is guessed from the content of cmt/requirements and CMakeLists.txt)
 
  1. Enter what you have tagged on the collector. Following your tagging, please commit all changes to the LHCbTagCollector, this is complicated, and much easier if you just do the tagging through the collector in the first place.
  2. Update the <Project>Sys package
    cd LbcomSys
    • in cmt/requirements update the version numbers of all the updated constituent packages
Changed:
<
<
    • in cmt/requirements update the <Package>Sys version number if not already done. The version must correspond to that used to tag the <PROJECT> package
>
>
    • in cmt/requirements and CMakeLists.txt update the <Package>Sys version number if not already done. The version must correspond to that used to tag the <PROJECT> package
 
    • in doc/release.notes and add, for each of the modified constituent packages, a summary of the release notes of the package.
    • Commit and tag
      svn commit -m v99r11
Changed:
<
<
tag_package LbcomSys v99r11
>
>
tag_package LbcomSys
 

Mandatory: Checks prior to release

  1. Check that the whole project is correctly tagged
Line: 200 to 199
 

Retagging:

Changed:
<
<
Often mistakes will be inadvertantly made, meaning a tag was not quite what it seemed.
>
>
Often mistakes will be inadvertently made, meaning a tag was not quite what it seemed.
 
  • Release managers have sufficient power over the repository to be able to retag existing packages.
  • But, this is a dangerous action, It is very easy to accidentally remove a tag from a different release.
  • Take great care when tagging and retagging packages
Changed:
<
<
Retagging involves removing the exisiting tag manually, using eclipse or on the command line, and then tagging the package with the same version as you would normally.
>
>
Retagging involves removing the existing tag manually, using eclipse or on the command line, and then tagging the package with the same version as you would normally.
 
  • e.g. removing
    svn rm svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LbcomSys/v99r11 -m 'removing v99r11 tag'
    
Line: 232 to 231
 Edit and commit the changes
emacs LHCB/LHCB_v34r3b/cmt/project.cmt
Changed:
<
<
svn commit -m "use a different version of Gaudi" LHCB/LHCB_v34r3b/cmt/project.cmt
>
>
emacs LHCB/LHCB_v34r3b/CMakeLists.txt svn commit -m "use a different version of Gaudi" LHCB/LHCB_v34r3b/cmt/project.cmt LHCB/LHCB_v34r3b/CMakeLists.txt
  Tag the project
Line: 251 to 251
 Edit the version in the requirements and the release notes, then commit.
emacs LHCbSys/cmt/requirements
Added:
>
>
emacs LHCbSys/CMakeLists.txt
 emacs LHCbSys/doc/release.notes svn commit -m "updated version" LHCbSys

Revision 202012-11-16 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 75 to 75
 Eclipse Commit

Copy the cmt directory from the trunk, then. Navigate to the tags/LBCOM directory, and make a new sub directory for LBCOM_v99r11. Then paste the cmt folder into this directory.

Added:
>
>
Repeat the copy&paste steps for all the files in the project directory (e.g. CMakeLists.txt, Makefile,...) and for the directory cmake (Note: this step is easier with the command line).
  Eclipse Tag

Revision 192012-06-29 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 215 to 215
  Tagging from a branch must at the moment be done on the command line, because all our release tools are not well setup to handle this. See SVNUsageGuidelines#Working_with_branches
Added:
>
>

Special procedures

Prepare a patch release just to use a different base project

If there is the need to pick up a bug fix in a base project and the overriding of a package is not enough (e.g. a change in a header of GaudiKernel), and the release that need a patch is not the latest one (trunk), it is necessary to branch the project and its container package.

Branch and modify the project

You can use the branch_package with the option -P:
branch_package -P LHCb -T v34r3 v34r3b
Check out the project file from the branch
getpack -P LHCb v34r3b
Edit and commit the changes
emacs LHCB/LHCB_v34r3b/cmt/project.cmt
svn commit -m "use a different version of Gaudi" LHCB/LHCB_v34r3b/cmt/project.cmt
Tag the project
tag_package -P LHCb -B v34r3b v34r3p1

Branch and modify the container package

Again, use the branch_package script (without -P)
branch_package LHCbSys -T v34r3 v34r3b
Check it out
getpack LHCbSys v34r3b
Edit the version in the requirements and the release notes, then commit.
emacs LHCbSys/cmt/requirements
emacs LHCbSys/doc/release.notes
svn commit -m "updated version" LHCbSys
Then tag
tag_package LHCbSys -B v34r3b

Test

Try the newly created tag by checking it out (remove the temporary directories you created before, working on the branches):
getpack --batch --no-config -Pr LHCb v34r3p1
Optionally, you can build and run the tests:
cd LHCB/LHCB_v34r3p1
make -j 20 CMTEXTRATAGS=use-distcc,no-pyzip tests
 -- MarcoCattaneo - 23-Jul-2010

META FILEATTACHMENT attachment="EclipseCheckout.png" attr="" comment="" date="1288215827" name="EclipseCheckout.png" path="EclipseCheckout.png" size="117958" stream="EclipseCheckout.png" tmpFilename="/usr/tmp/CGItemp18674" user="rlambert" version="1"

Revision 182011-12-16 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 108 to 108
 getpack -P -H LBCOM HEAD cd LBCOM/LBCOM_HEAD
    • edit cmt/project.cmt to update the dependencies of the project
Changed:
<
<
    • commit and tag with the new version number:
>
>
    • commit and tag with the new version number (for example v99r11):
 
Changed:
<
<
svn commit -m "dependencies for v99r11 release" svn mkdir svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LBCOM/LBCOM_v99r11 -m "tag directory for v99r11 release" svn cp svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/trunk/cmt svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LBCOM/LBCOM_v99r11 -m "tag dependencies for v99r11 release"
>
>
cd cmt svn commit -m v99r11 cd .. tag_package -P Lbcom v99r11
 
  1. Tag all the packages that are updated for the release. The packages to be updated should be documented in the LHCbTagCollector.
    • Take the appropriate section of the tag collector page and, for each package mentioned in there:

Revision 172011-11-10 - ChristopherRJones

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group

Revision 162011-11-10 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 48 to 48
 Eclipse is an integrated set of IDE's which provides the same look-and-feel to many different IDEs and functions. It also has a complete SVN interface which is very user-friendly. To configure eclipse correctly for LHCb see EclipseConfiguration.

Before you try and use eclipse, it's a good idea to understand a bit about it, get familiar with the most basic operations, such as opening different perspectives, looking through the Gaudi/LHCb svn repositories, etc.

Changed:
<
<
>
>
 

Checks before tagging

Revision 152011-11-10 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 47 to 47
  Eclipse is an integrated set of IDE's which provides the same look-and-feel to many different IDEs and functions. It also has a complete SVN interface which is very user-friendly. To configure eclipse correctly for LHCb see EclipseConfiguration.
Added:
>
>
Before you try and use eclipse, it's a good idea to understand a bit about it, get familiar with the most basic operations, such as opening different perspectives, looking through the Gaudi/LHCb svn repositories, etc.
 

Checks before tagging

You can check if anyone has made a change which has not appeared on the tag collector. Login to the tag collector and go to Lost Tags. Type and choose from the auto fill the name of the package. If someone has made a modification, but not put it on the tag collector it will appear in the list of "Missing Tags".

Revision 142011-09-08 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 12 to 12
  There are two different methods of preparing the release, these are interchangable and it is advisable to be familiar with both. Either you can use a GUI-based method, revolving around the Tag Collector and Eclipse, or a command-line based method which requires a lot of disk space and usually more time.
Added:
>
>

Prerequisites

  • You are assumed to be familiar with svn.
  • You are assumed to be familiar with our project/package structure.
  • You are assumed to already have been a developer of the software you are now releasing. Now you are a manager.
  • You will have read and understood the SVNUsageModel
  • You are familiar with, and adhere to, all the SVNUsageGuidelines

Tools and terms

Term Explanation
the head The most recent software with all committed modifications. Also known as the trunk in svn.
branch A development offshoot which is not compatible with the head and must be handled carefully.
a tag A persistent coherent snapshot of software at a given point in time. A versioned piece of software indicated by the tag name.
an official tag A tag with a name of the form vXrY.
a user tag A tag with the form <user>_yyyymmdd
tagging within the release system, this is the action of creating a tag or set of coherent tags.
tag collecting The collecting of changesets and modifications which are expected to go into a tag. Tag collecting is not tagging.
the tag collector a website interface to a database where revisions are collected before official tags are made

Tool Explanation Example
svn info Find information about a local checked out package such as the last person to modify it and the svn path svn info
getpack Checkout from the repository by package name, no need to know the full path to the repository. getpack -rH LHCbSys head
tag_package Create a tag of a package. Usually this means copying from on svn location to another tag_package MyHat/MyPackage me_20110907
svnCheckTags Check that the packages and tags requested in a given requirements file or project.cmt exist. Can also compare the contents with the trunk. svnCheckTags Rec v12r0 --diffs
svnDiffTags Compare the contents of two tagged versions of a package or project and its dependent packages svnDiffTags Rec v11r0 v12r0
cmpPackageWithTrunk compare the content of a checked-out (and modified) version of the software with the trunk cmpPackageWithTrunk --all
 

Option 1: Tag Collector and Eclipse

The Tag Collector has a lot of release-manager helper features.

Line: 108 to 137
 

Mandatory: Checks prior to release

  1. Check that the whole project is correctly tagged
Changed:
<
<
    • Go to a root working directory with a lot of space, and check out the tagged project as it will be released
      getpack --project -r LBCOM v99r11
    • If everything checks out correctly, you are almost done.

  1. Check that nothing has been missed from the release
       cd LBCOM/LBCOM_v99r11
       cmpPackageWithTrunk --all
    This gives you any files that are in the trunk of SVN but not included in the release tag. This is either because you made a mistake in the tagging above, or because the changes were not included in the tag collector, either on purpose or by accident. In the latter case decide if the changes should anyway be included - either unilaterally or in consultation with the author of the changes. To add new tags:
    • go to the package to be updated, under LBCOM/LBCOM_HEAD
    • tag the missing package as above
    • update LBCOM_HEAD/LbcomSys/cmt/requirements and LBCOM_HEAD/LbcomSys/doc/release.notes
    • commit and retag (you have to remove the previous tag before tagging again. Take care!):
      svn commit -m 'updating v99r11'
      svn rm svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LbcomSys/v99r11 -m 'removing v99r11 tag'
      tag_package LbcomSys v99r11
    • go back to LBCOM/LBCOM_v99r11:
>
>
    • It is now possible to do this directly through SVN:
      svnCheckTags Lbcom v99r11
    • This will print warnings and errors if tags are missing.
    • In case of missing or incorrect tags, you may have to retag the Sys package

  1. Check that nothing has been missed from the release
    svnCheckTags Lbcom v99r11 --diffs
    This gives you any files that are in the trunk of SVN but not included in the release tag. This is either because you made a mistake in the tagging above, or because the changes were not included in the tag collector, either on purpose or by accident. Usually this is avoided by checking the LostTags of the TagCollector before this stage. In the latter case decide if the changes should anyway be included - either unilaterally or in consultation with the author of the changes. You may have to retag.
  2. Check that getpack has no problems with the packages
    • That the tags exist on svn usually proves everything is fine, but to be doubly sure you can check that getpack will find all the packages
    • go somewhere with a lot of free disc space
 
Changed:
<
<
getpack / getpack LbcomSys v99r11
    • check again that you now have all the wanted changes: cmpPackageWithTrunk --all
>
>
getpack --project -r LBCOM v99r11
    • if the getpack works, then you are ready for the release.
 

Add a new version of the project to the tag collector

Once you have tagged the project, you should avoid having new package revisions added to the project in the tag collector. Create a "New Project" where people can add new revisions, and edit the description of the project to be released to say that the project is tagged and frozen and no new package revisions should be added
Line: 170 to 192
  Common problems are documented in the SVNUsageModel, hopefully all will be protected by pre-commit-hooks in the future.
Added:
>
>

Retagging:

Often mistakes will be inadvertantly made, meaning a tag was not quite what it seemed.

  • Release managers have sufficient power over the repository to be able to retag existing packages.
  • But, this is a dangerous action, It is very easy to accidentally remove a tag from a different release.
  • Take great care when tagging and retagging packages

Retagging involves removing the exisiting tag manually, using eclipse or on the command line, and then tagging the package with the same version as you would normally.

  • e.g. removing
    svn rm svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LbcomSys/v99r11 -m 'removing v99r11 tag'
    

Branching:

Branching is required whenever a developer needs to modify code in an incompatible way with the existing head. This should always be discussed with the release manager.

Tagging from a branch must at the moment be done on the command line, because all our release tools are not well setup to handle this. See SVNUsageGuidelines#Working_with_branches

 -- MarcoCattaneo - 23-Jul-2010

META FILEATTACHMENT attachment="EclipseCheckout.png" attr="" comment="" date="1288215827" name="EclipseCheckout.png" path="EclipseCheckout.png" size="117958" stream="EclipseCheckout.png" tmpFilename="/usr/tmp/CGItemp18674" user="rlambert" version="1"

Revision 132011-08-29 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 95 to 95
 
svn commit -m <theNewOfficialTag>
tag_package Hat/Package <theNewOfficialTag>
Added:
>
>
  1. Enter what you have tagged on the collector. Following your tagging, please commit all changes to the LHCbTagCollector, this is complicated, and much easier if you just do the tagging through the collector in the first place.
 
  1. Update the <Project>Sys package
    cd LbcomSys
    • in cmt/requirements update the version numbers of all the updated constituent packages

Revision 122011-04-29 - PatrickSKoppenburg

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 72 to 72
 
  1. Update the project dependencies and tag the <PROJECT> package
    • check out the HEAD of the complete project

Changed:
<
<
getpack -P -rh LBCOM HEAD
>
>
getpack -P -H LBCOM HEAD
 cd LBCOM/LBCOM_HEAD
    • edit cmt/project.cmt to update the dependencies of the project
    • commit and tag with the new version number:
Line: 94 to 94
 
    • commit and tag with the new version number:
      svn commit -m <theNewOfficialTag>
Changed:
<
<
tag_package
>
>
tag_package Hat/Package
 
  1. Update the <Project>Sys package
    cd LbcomSys
    • in cmt/requirements update the version numbers of all the updated constituent packages

Revision 112011-04-06 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 129 to 129
 getpack LbcomSys v99r11
    • check again that you now have all the wanted changes: cmpPackageWithTrunk --all
Added:
>
>

Add a new version of the project to the tag collector

Once you have tagged the project, you should avoid having new package revisions added to the project in the tag collector. Create a "New Project" where people can add new revisions, and edit the description of the project to be released to say that the project is tagged and frozen and no new package revisions should be added
 

Mandatory: Nightly test of the software

The tagged software should be built and tested at least once in the LHCbNightlies build system.
Line: 156 to 159
 

Mandatory: Request @ Savannah

If the nightly tests are successful, you can ask for a release. The release request has to be made in the task tracker of the LHCb Deployment Savannah project.
Added:
>
>

Clean up the tag collector

Once you have made the release request, you should "hide" the project from the tag collector, by clicking on the red cross to the right of the project heading and answering OK to the following questions. Before you do so, check that no-one has added new package revisions after you tagged the project. If any were added, move them to a newer version of the project, using the "Edit" button next to the package revision entry.
 

Document the release

The doxygen documentation of the project is made automatically by the release procedure. But the project release pages (e.g. http://cern.ch/LHCb-release-area/DOC/lbcom/) have to be updated by hand, see instructions here

Revision 92010-12-17 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 10 to 10
  There are two different methods of preparing the release, these are interchangable and it is advisable to be familiar with both. Either you can use a GUI-based method, revolving around the Tag Collector and Eclipse, or a command-line based method which requires a lot of disk space and usually more time.
Changed:
<
<

Tag Collector and Eclipse

>
>

Option 1: Tag Collector and Eclipse

  The Tag Collector has a lot of release-manager helper features.
Line: 58 to 58
  Edit the requirements file and release notes to give all the changes and new tags you have incorporated in this verison, then click submit, and that's you done.
Changed:
<
<

Command-line based

>
>

Option 2: Command-line based

 

Tagging

The project has to be correctly tagged in order to be ready for release.
Line: 103 to 103
 svn commit -m v99r11 tag_package LbcomSys v99r11
Changed:
<
<

Checks prior to release

>
>

Mandatory: Checks prior to release

 
  1. Check that the whole project is correctly tagged
    • Go to a root working directory with a lot of space, and check out the tagged project as it will be released
      getpack --project -r LBCOM v99r11
Line: 127 to 127
 getpack LbcomSys v99r11
    • check again that you now have all the wanted changes: cmpPackageWithTrunk --all
Changed:
<
<

Nightly test of the software

The tagged software should be built and tested at least once in the LHCb nightly system. Ask someone with write access to the nightlies configuration file (Karol, Marco, Marco, Hubert, Gloria...) to add the tagged project to an appropriate slot of the nightlies (usually lhcb-prerelease slot)
>
>

Mandatory: Nightly test of the software

The tagged software should be built and tested at least once in the LHCbNightlies build system.
 
Changed:
<
<

Request @ Savannah

>
>
Go to the nightlies page, and spawn the configuration editor to add your project into the lhcb-prerelease slot. Usually this means updating the existing entry by double-clicking the version.

Nightly Editor

Writing the release notes

The release notes for different projects follow different models and have different levels of verbosity. The release managers are at liberty to determine the verbosity, but all major changes which will modify the content of the output files, the look and feel of the program, or the user experience should be well-documented.

One simple way to compile a list of all the changes is to use the tag collector 'display.html', which provides a static URL for the tag collector entries for that release

This URL can be inserted in the usual release.notes to reduce the amount of writing, and speed up the release procedure for you. It has the added advantages that the changesets in SVN, and savannah bug reports are linked directly, so persons looking through the release.notes can get a very clear picture of what has happened.

  • In the case you have used the tag collector to collect and tag all included packages, you can place the fixed url for the changes into the release notes, rather than writing them yourself.
  • In the case you haven't used the tag collector, or not all the changes are in the tag collector, then you are at liberty to write your own subsequent comments.
  • In either case there will be some release notes you'll want to add by hand anyway, to describe the purpose of the release and highlight major changes.

Mandatory: Request @ Savannah

 If the nightly tests are successful, you can ask for a release. The release request has to be made in the task tracker of the LHCb Deployment Savannah project.

Document the release

Line: 147 to 168
 
META FILEATTACHMENT attachment="EclipseTag.png" attr="" comment="" date="1288215848" name="EclipseTag.png" path="EclipseTag.png" size="159395" stream="EclipseTag.png" tmpFilename="/usr/tmp/CGItemp18494" user="rlambert" version="1"
META FILEATTACHMENT attachment="LostTags.png" attr="" comment="" date="1288215867" name="LostTags.png" path="LostTags.png" size="52082" stream="LostTags.png" tmpFilename="/usr/tmp/CGItemp18662" user="rlambert" version="1"
META FILEATTACHMENT attachment="TagPackage.png" attr="" comment="" date="1288215885" name="TagPackage.png" path="TagPackage.png" size="74159" stream="TagPackage.png" tmpFilename="/usr/tmp/CGItemp18586" user="rlambert" version="1"
Added:
>
>
META FILEATTACHMENT attachment="NightlyEditor.png" attr="" comment="NIghtly editor screenshot" date="1292586768" name="NightlyEditor.png" path="NightlyEditor.png" size="92790" stream="NightlyEditor.png" tmpFilename="/usr/tmp/CGItemp15899" user="rlambert" version="1"

Revision 82010-11-18 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 136 to 136
 

Document the release

The doxygen documentation of the project is made automatically by the release procedure. But the project release pages (e.g. http://cern.ch/LHCb-release-area/DOC/lbcom/) have to be updated by hand, see instructions here
Added:
>
>

Common problems/mistakes:

Common problems are documented in the SVNUsageModel, hopefully all will be protected by pre-commit-hooks in the future.

 -- MarcoCattaneo - 23-Jul-2010

META FILEATTACHMENT attachment="EclipseCheckout.png" attr="" comment="" date="1288215827" name="EclipseCheckout.png" path="EclipseCheckout.png" size="117958" stream="EclipseCheckout.png" tmpFilename="/usr/tmp/CGItemp18674" user="rlambert" version="1"

Revision 72010-10-27 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 8 to 8
 

Introduction

The procedure described below is a suggested procedure. Mandatory steps are highlighted in RED. In the code examples below, we assume you are releasing project LBCOM version v99r11.
Changed:
<
<

Tagging

>
>
There are two different methods of preparing the release, these are interchangable and it is advisable to be familiar with both. Either you can use a GUI-based method, revolving around the Tag Collector and Eclipse, or a command-line based method which requires a lot of disk space and usually more time.

Tag Collector and Eclipse

The Tag Collector has a lot of release-manager helper features.

Eclipse is an integrated set of IDE's which provides the same look-and-feel to many different IDEs and functions. It also has a complete SVN interface which is very user-friendly. To configure eclipse correctly for LHCb see EclipseConfiguration.

Checks before tagging

You can check if anyone has made a change which has not appeared on the tag collector. Login to the tag collector and go to Lost Tags. Type and choose from the auto fill the name of the package. If someone has made a modification, but not put it on the tag collector it will appear in the list of "Missing Tags".

You can then select the radio button to see what the revisions were which were not requested in the tag collector, and then either add it to the tag collector, or more likely, contact the author to request clarification.

Lost Tags

Tagging

The project has to be correctly tagged in order to be ready for release. A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package and project.cmt file have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.

  • Update the project dependencies and tag the <PROJECT> package

Firstly, you need to make the project structure inside Eclipse. Switch to the SVN view and navigate down to the project directory. Checkout the cmt directory any make any needed modifications to the project.cmt file.

Eclipse Checkout

Then right click on the modified file, and go to Team->Commit, to commit it to the trunk.

Eclipse Commit

Copy the cmt directory from the trunk, then. Navigate to the tags/LBCOM directory, and make a new sub directory for LBCOM_v99r11. Then paste the cmt folder into this directory.

Eclipse Tag

  • Tag all the packages that are updated for the release. The packages to be updated should be documented in the LHCbTagCollector.

Next you should tag all the packages using the TagPackage page of the tag collector. For each modified package on the tag collector, fill out this form. It autocompletes, so first select the package name, then the project will be suggested. Click in the version box and it will be filled for you, the requirements file and release notes will be downloaded from SVN.

You can freely modify the requirements and release notes, are free to choose the name of the next version, and can insert the tagging comment automatically by clicking the button. Once you are satisfied, choose submit to commit your changes to SVN and tag the package with the version you have given.

TagPackage

  • Update the <Project>Sys package

Then there is only one package left to modify, the Sys package, in this case you want to create LbcomSys v99r11, which can be easily acheived by having the Tag Collector main page open in one window, and the Tag Package script open in another.

Edit the requirements file and release notes to give all the changes and new tags you have incorporated in this verison, then click submit, and that's you done.

Command-line based

Tagging

 The project has to be correctly tagged in order to be ready for release. A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package and project.cmt file have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
Line: 53 to 105
 

Checks prior to release

  1. Check that the whole project is correctly tagged
Changed:
<
<
    • Go back to your root working directory and check out the tagged project as it will be released
>
>
    • Go to a root working directory with a lot of space, and check out the tagged project as it will be released
 
getpack --project -r LBCOM v99r11
    • If everything checks out correctly, you are almost done.

  1. Check that nothing has been missed from the release
Line: 85 to 137
 The doxygen documentation of the project is made automatically by the release procedure. But the project release pages (e.g. http://cern.ch/LHCb-release-area/DOC/lbcom/) have to be updated by hand, see instructions here

-- MarcoCattaneo - 23-Jul-2010 \ No newline at end of file

Added:
>
>
META FILEATTACHMENT attachment="EclipseCheckout.png" attr="" comment="" date="1288215827" name="EclipseCheckout.png" path="EclipseCheckout.png" size="117958" stream="EclipseCheckout.png" tmpFilename="/usr/tmp/CGItemp18674" user="rlambert" version="1"
META FILEATTACHMENT attachment="EclipseCommit.png" attr="" comment="" date="1288215837" name="EclipseCommit.png" path="EclipseCommit.png" size="154800" stream="EclipseCommit.png" tmpFilename="/usr/tmp/CGItemp18632" user="rlambert" version="1"
META FILEATTACHMENT attachment="EclipseTag.png" attr="" comment="" date="1288215848" name="EclipseTag.png" path="EclipseTag.png" size="159395" stream="EclipseTag.png" tmpFilename="/usr/tmp/CGItemp18494" user="rlambert" version="1"
META FILEATTACHMENT attachment="LostTags.png" attr="" comment="" date="1288215867" name="LostTags.png" path="LostTags.png" size="52082" stream="LostTags.png" tmpFilename="/usr/tmp/CGItemp18662" user="rlambert" version="1"
META FILEATTACHMENT attachment="TagPackage.png" attr="" comment="" date="1288215885" name="TagPackage.png" path="TagPackage.png" size="74159" stream="TagPackage.png" tmpFilename="/usr/tmp/CGItemp18586" user="rlambert" version="1"

Revision 62010-08-30 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

Changed:
<
<
This wiki explains the procedure to be used by software project managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here
>
>
This wiki explains the procedure to be used by software release managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
 

Revision 52010-07-23 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

Changed:
<
<
This wiki explains the procedure to be used by software project managers to prepare a project for release.
>
>
This wiki explains the procedure to be used by software project managers to prepare a project for release. It assumes the project is in SVN. For projects still in CVS, see the similar procedure here
 
Line: 10 to 10
 

Tagging

The project has to be correctly tagged in order to be ready for release.
Changed:
<
<
A project release consists of a set of constituent packages each of which is tagged with a CVS tag. The <Project>Sys and <PROJECT> CVS modules have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
>
>
A project release consists of a set of constituent packages each of which is tagged. An SVN tag is simply a copy of the package on the 'trunk' to a 'tags' directory. The <Project>Sys package and project.cmt file have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
 
Changed:
<
<
The following is the recommended procedure for tagging the packages and project. Note that the procedure applies to projects. For data packages, it's enough to just cvs tag the package, as in the last step.
>
>
The following is the recommended procedure for tagging the packages and project. Note that the procedure applies to projects. For data packages, it's enough to just tag the package, as in the last step.
 
  1. Go to a working directory with lots of quota (typically a directory on a local disk of your machine)

  2. Update the project dependencies and tag the <PROJECT> package
Line: 22 to 22
 cd LBCOM/LBCOM_HEAD
    • edit cmt/project.cmt to update the dependencies of the project
    • commit and tag with the new version number:
Deleted:
<
<
      1. SVN case
 
svn commit -m "dependencies for v99r11 release"
svn mkdir svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LBCOM/LBCOM_v99r11 -m "tag directory for v99r11 release"
svn cp svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/trunk/cmt svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LBCOM/LBCOM_v99r11 -m "tag dependencies for v99r11 release"
Deleted:
<
<
      1. CVS case
        cvs commit -m "dependencies for v99r11 release"
        cvs rtag LBCOM_v99r11 LBCOM
 
  1. Tag all the packages that are updated for the release. The packages to be updated should be documented in the LHCbTagCollector.
    • Take the appropriate section of the tag collector page and, for each package mentioned in there:
      cd <theHat>/<thePackage>
Changed:
<
<
cvs diff -r
    • If there are no diffs, all is well, the head of CVS corresponds to the tag that should be released. If there are diffs, you have to decide whether you want to include them in the release - either unilaterally or in consultation with the author of the changes.
>
>
svn info
    • If the Revision corresponds to the revision given in the tag collector, all is well, the package trunk corresponds to the version that should be released. If the Revision is different, you have to decide whether you want to include them in the release - either unilaterally or in consultation with the author of the changes. You can check the differences with svn diff -r <someRevision>, where <someRevision> is the revision with which you want to compare, for example the revision given in the tag collector. If all is well,
 
    • In doc/release.notes, add the line with release version number and date
      • If already added by the package manager, check that the version number is correct, and that they haven't moved the line from a previous release - yes I happens!)
    • Check that cmt/requirements contains the new version number
Changed:
<
<
      • If not, update it (don't rely on the version that people have put in the tag collector being correct)
>
>
      • If not, update it
 
    • commit and tag with the new version number:

Changed:
<
<
cvs commit -m cvs rtag
>
>
svn commit -m tag_package
 
  1. Update the <Project>Sys package
    cd LbcomSys
    • in cmt/requirements update the version numbers of all the updated constituent packages
Line: 53 to 48
 
    • in doc/release.notes and add, for each of the modified constituent packages, a summary of the release notes of the package.
    • Commit and tag

Changed:
<
<
cvs commit -m v99r11 cvs rtag v99r11 LbcomSys
>
>
svn commit -m v99r11 tag_package LbcomSys v99r11
 

Checks prior to release

  1. Check that the whole project is correctly tagged
Line: 64 to 59
 
  1. Check that nothing has been missed from the release
       cd LBCOM/LBCOM_v99r11
Changed:
<
<
cvs -n update -A This gives you any files that are in the head of CVS but not included in the release tag. This is either because you made a mistake in the tagging above, or because the changes were not included in the tag collector, either on purpose or by accident. In the latter case decide if the changes should anyway be included - either unilaterally or in consultation with the author of the changes. To add new tags:
>
>
cmpPackageWithTrunk --all This gives you any files that are in the trunk of SVN but not included in the release tag. This is either because you made a mistake in the tagging above, or because the changes were not included in the tag collector, either on purpose or by accident. In the latter case decide if the changes should anyway be included - either unilaterally or in consultation with the author of the changes. To add new tags:
 
    • go to the package to be updated, under LBCOM/LBCOM_HEAD
    • tag the missing package as above
    • update LBCOM_HEAD/LbcomSys/cmt/requirements and LBCOM_HEAD/LbcomSys/doc/release.notes
Changed:
<
<
    • commit and retag (cvs rtag -F v99r11 LbcomSys/cmt/requirements)
>
>
    • commit and retag (you have to remove the previous tag before tagging again. Take care!):
      svn commit -m 'updating v99r11'
      svn rm svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LbcomSys/v99r11 -m 'removing v99r11 tag'
      tag_package LbcomSys v99r11
 
    • go back to LBCOM/LBCOM_v99r11:

Changed:
<
<
cd / cvs update -r cd ../../LbcomSys cvs update cd ..
    • check again that you now have all the wanted changes: cvs -n update -A
>
>
getpack / getpack LbcomSys v99r11
    • check again that you now have all the wanted changes: cmpPackageWithTrunk --all
 

Nightly test of the software

Changed:
<
<
The tagged software should be built and tested at least once in the LHCb nightly system. Ask someone with write access to the nightlies configuration file (Karol, Marco, Marco, Hubert, Gloria...) to add the tagged project to an appropriate slot of the nightlies (usually lhcb2 slot)
>
>
The tagged software should be built and tested at least once in the LHCb nightly system. Ask someone with write access to the nightlies configuration file (Karol, Marco, Marco, Hubert, Gloria...) to add the tagged project to an appropriate slot of the nightlies (usually lhcb-prerelease slot)
 

Request @ Savannah

If the nightly tests are successful, you can ask for a release. The release request has to be made in the task tracker of the LHCb Deployment Savannah project.
Line: 88 to 84
 

Document the release

The doxygen documentation of the project is made automatically by the release procedure. But the project release pages (e.g. http://cern.ch/LHCb-release-area/DOC/lbcom/) have to be updated by hand, see instructions here
Deleted:
<
<
-- MarcoCattaneo - 02-Dec-2009
 \ No newline at end of file
Added:
>
>
-- MarcoCattaneo - 23-Jul-2010

Revision 42010-07-20 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software project managers to prepare a project for release.
Line: 8 to 8
 

Introduction

The procedure described below is a suggested procedure. Mandatory steps are highlighted in RED. In the code examples below, we assume you are releasing project LBCOM version v99r11.
Changed:
<
<

CVS tagging

>
>

Tagging

 The project has to be correctly tagged in order to be ready for release. A project release consists of a set of constituent packages each of which is tagged with a CVS tag. The <Project>Sys and <PROJECT> CVS modules have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.
Line: 16 to 16
 
  1. Go to a working directory with lots of quota (typically a directory on a local disk of your machine)

  2. Update the project dependencies and tag the <PROJECT> package
Changed:
<
<
    • check out the <PROJECT> package
>
>
    • check out theHEAD of the complete project
 
Changed:
<
<
getpack --project LBCOM HEAD
>
>
getpack -P -rh LBCOM HEAD
 cd LBCOM/LBCOM_HEAD
    • edit cmt/project.cmt to update the dependencies of the project
    • commit and tag with the new version number:
Added:
>
>
      1. SVN case
 
Changed:
<
<
cvs commit -m "update dependencies"
>
>
svn commit -m "dependencies for v99r11 release" svn mkdir svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LBCOM/LBCOM_v99r11 -m "tag directory for v99r11 release" svn cp svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/trunk/cmt svn+ssh://svn.cern.ch/reps/lhcb/Lbcom/tags/LBCOM/LBCOM_v99r11 -m "tag dependencies for v99r11 release"
      1. CVS case
        cvs commit -m "dependencies for v99r11 release"
 cvs rtag LBCOM_v99r11 LBCOM
Changed:
<
<
  1. Tag all the packages that are updated for the release. This can be done by checking out one package at a time, but it is simpler to follow the procedure below:
    • Check out the head of all packages in the project:
      getpack -rh LbcomSys head
    • The packages to be updated should be documented in the LHCbTagCollector. Take the appropriate section of the tag collector page and, for each package mentioned in there:
>
>
  1. Tag all the packages that are updated for the release. The packages to be updated should be documented in the LHCbTagCollector.
    • Take the appropriate section of the tag collector page and, for each package mentioned in there:
 
cd <theHat>/<thePackage>
cvs diff -r <theLastUserTag>

Revision 32010-02-25 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"

Preparing a software project for release

This wiki explains the procedure to be used by software project managers to prepare a project for release.
Line: 40 to 40
 
    • commit and tag with the new version number:
      cvs commit -m <theNewOfficialTag>
Changed:
<
<
cvs rtag
  1. Update the =<Project> package=
>
>
cvs rtag
  1. Update the <Project>Sys package
 
cd LbcomSys
    • in cmt/requirements update the version numbers of all the updated constituent packages
    • in cmt/requirements update the <Package>Sys version number if not already done. The version must correspond to that used to tag the <PROJECT> package

Revision 22009-12-02 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="ProjectRelease"
Changed:
<
<

Introduction

>
>

Preparing a software project for release

 This wiki explains the procedure to be used by software project managers to prepare a project for release.
Added:
>
>

Introduction

The procedure described below is a suggested procedure. Mandatory steps are highlighted in RED. In the code examples below, we assume you are releasing project LBCOM version v99r11.
 

CVS tagging

Changed:
<
<
The project has to be correctly tagged in order to be ready for the deployment. Both the <Project>Sys and <PROJECT> CVS modules have to be tagged for the <version> tag:
>
>
The project has to be correctly tagged in order to be ready for release. A project release consists of a set of constituent packages each of which is tagged with a CVS tag. The <Project>Sys and <PROJECT> CVS modules have to be tagged with the project <version>. The list of constituent packages and tags to be released is found in the <Project>Sys/cmt/requirements file.

The following is the recommended procedure for tagging the packages and project. Note that the procedure applies to projects. For data packages, it's enough to just cvs tag the package, as in the last step.

 
Changed:
<
<
  1. The container package <Project>Sys has to be updated with the correct versions of the different packages of the project.
  2. Change the version of the container package <Project>Sys to <version>. Commit and tag it to <version>.
>
>
  1. Go to a working directory with lots of quota (typically a directory on a local disk of your machine)

  2. Update the project dependencies and tag the <PROJECT> package
    • check out the <PROJECT> package
      getpack --project LBCOM HEAD
      cd LBCOM/LBCOM_HEAD
    • edit cmt/project.cmt to update the dependencies of the project
    • commit and tag with the new version number:
      cvs commit -m "update dependencies"
      cvs rtag LBCOM_v99r11 LBCOM
  3. Tag all the packages that are updated for the release. This can be done by checking out one package at a time, but it is simpler to follow the procedure below:
    • Check out the head of all packages in the project:
      getpack -rh LbcomSys head
    • The packages to be updated should be documented in the LHCbTagCollector. Take the appropriate section of the tag collector page and, for each package mentioned in there:
      cd <theHat>/<thePackage>
      cvs diff -r <theLastUserTag>
    • If there are no diffs, all is well, the head of CVS corresponds to the tag that should be released. If there are diffs, you have to decide whether you want to include them in the release - either unilaterally or in consultation with the author of the changes.
    • In doc/release.notes, add the line with release version number and date
      • If already added by the package manager, check that the version number is correct, and that they haven't moved the line from a previous release - yes I happens!)
    • Check that cmt/requirements contains the new version number
      • If not, update it (don't rely on the version that people have put in the tag collector being correct)
    • commit and tag with the new version number:
      cvs commit -m <theNewOfficialTag>
      cvs rtag <theNewOfficialTag> <theNewOfficialTag>
  4. Update the =<Project> package=
    cd LbcomSys
    • in cmt/requirements update the version numbers of all the updated constituent packages
    • in cmt/requirements update the <Package>Sys version number if not already done. The version must correspond to that used to tag the <PROJECT> package
    • in doc/release.notes and add, for each of the modified constituent packages, a summary of the release notes of the package.
    • Commit and tag
 
Changed:
<
<
cvs rtag -r Sys
  1. Update the <PROJECT>/cmt/project.cmt file, ensure that the dependencies are correct and coherent.
  2. Commit it and tag it with <PROJECT>_<version>.
           cvs rtag -r <PROJECT>_<version> <PROJECT>
  3. If the project has been correctly tagged, a full project checkout should work:
              getpack -r -P <Project> <version>
Note: If the project would be MyProj and the version v1r2, one would have to use <Project>=MyProj, <PROJECT>=MYPROJ, <version>=v1r2, <PROJECT>_<version>=MYPROJ_v1r2.

Data packages

For data packages, it's enough to just cvs tag the package, as in steps 1 and 2 above.
>
>
cvs commit -m v99r11 cvs rtag v99r11 LbcomSys

Checks prior to release

  1. Check that the whole project is correctly tagged
    • Go back to your root working directory and check out the tagged project as it will be released
      getpack --project -r LBCOM v99r11
    • If everything checks out correctly, you are almost done.

  2. Check that nothing has been missed from the release
       cd LBCOM/LBCOM_v99r11
       cvs -n update -A
    This gives you any files that are in the head of CVS but not included in the release tag. This is either because you made a mistake in the tagging above, or because the changes were not included in the tag collector, either on purpose or by accident. In the latter case decide if the changes should anyway be included - either unilaterally or in consultation with the author of the changes. To add new tags:
    • go to the package to be updated, under LBCOM/LBCOM_HEAD
    • tag the missing package as above
    • update LBCOM_HEAD/LbcomSys/cmt/requirements and LBCOM_HEAD/LbcomSys/doc/release.notes
    • commit and retag (cvs rtag -F v99r11 LbcomSys/cmt/requirements)
    • go back to LBCOM/LBCOM_v99r11:
      cd <theHat>/<theModifiedPackage>
      cvs update -r <theNewTag>
      cd ../../LbcomSys
      cvs update
      cd ..
    • check again that you now have all the wanted changes: cvs -n update -A
 

Nightly test of the software

Changed:
<
<
The tagged software should have been built and tested at least once in the LHCb nightly system.
>
>
The tagged software should be built and tested at least once in the LHCb nightly system. Ask someone with write access to the nightlies configuration file (Karol, Marco, Marco, Hubert, Gloria...) to add the tagged project to an appropriate slot of the nightlies (usually lhcb2 slot)
 

Request @ Savannah

Changed:
<
<
The deployment request has to be made in the task tracker of the LHCb Deployment Savannah project.
>
>
If the nightly tests are successful, you can ask for a release. The release request has to be made in the task tracker of the LHCb Deployment Savannah project.
 
Added:
>
>

Document the release

The doxygen documentation of the project is made automatically by the release procedure. But the project release pages (e.g. http://cern.ch/LHCb-release-area/DOC/lbcom/) have to be updated by hand, see instructions here
  -- MarcoCattaneo - 02-Dec-2009 \ No newline at end of file

Revision 12009-12-02 - MarcoCattaneo

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="ProjectRelease"

Introduction

This wiki explains the procedure to be used by software project managers to prepare a project for release.

CVS tagging

The project has to be correctly tagged in order to be ready for the deployment. Both the <Project>Sys and <PROJECT> CVS modules have to be tagged for the <version> tag:

  1. The container package <Project>Sys has to be updated with the correct versions of the different packages of the project.
  2. Change the version of the container package <Project>Sys to <version>. Commit and tag it to <version>.
           cvs rtag -r <version> <Project>Sys
  3. Update the <PROJECT>/cmt/project.cmt file, ensure that the dependencies are correct and coherent.
  4. Commit it and tag it with <PROJECT>_<version>.
           cvs rtag -r <PROJECT>_<version> <PROJECT>
  5. If the project has been correctly tagged, a full project checkout should work:
              getpack -r -P <Project> <version>
Note: If the project would be MyProj and the version v1r2, one would have to use <Project>=MyProj, <PROJECT>=MYPROJ, <version>=v1r2, <PROJECT>_<version>=MYPROJ_v1r2.

Data packages

For data packages, it's enough to just cvs tag the package, as in steps 1 and 2 above.

Nightly test of the software

The tagged software should have been built and tested at least once in the LHCb nightly system.

Request @ Savannah

The deployment request has to be made in the task tracker of the LHCb Deployment Savannah project.

-- MarcoCattaneo - 02-Dec-2009

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback