Difference: PrepareProjectReleaseGit (1 vs. 9)

Revision 92019-02-13 - MarcoCattaneo

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

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 gitlab. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 33 to 33
 git checkout -b vXrY-release %ENDCODE% Update the project version and dependencies
Changed:
<
<
  • In the files CMakeLists.txt, MyProjectSys/CMakeLists.txt, update the project version number to vXrY
  • In the file CMakeLists.txt, update the project dependencies (i.e. change the version of used projects if they have changed)
>
>
  • In the file CMakeLists.txt, update the project version number to vXrY and update the project dependencies (i.e. change the version of used projects if they have changed)
 
  • For projects that depend on Gaudi versions prior to v28r0, do the corresponding thing also for the CMT files:
    • In the file MyProjectSys/cmt/requirements, update the project version number to vXrY
    • In the file cmt/project.cmt, update the project dependencies (i.e. change the version of used projects if they have changed)
Update the release notes
Changed:
<
<
  • It is suggested to use the merge request comments of all the merge requests accepted since the last (e.g. vXr(Y-1)) release. Use the following command to extract them to a file vXrY.log. N.B.: note the trailing ".." of the command, it is important
>
>
  • It is suggested to use the merge request descriptions of all the merge requests accepted since the last (e.g. vXr(Y-1)) release. Use the following command:
 %CODE{"bash"}%
Changed:
<
<
git log --name-only --first-parent vXr(Y-1).. > vXrY.log
>
>
lb-gen-release-notes vXr(Y-1) vXrY
 %ENDCODE%
Changed:
<
<
Now create the file ReleaseNote/vXrY.md to add information on the release, based on what you extracted into vXrY.log.
  • It is recommended to preserve the formatting used in previous releases; you are encouraged to use the gitlab markdown to link to the merge requests included in the release.
  • Please note that the above command extracts only the git merge messages. If you want to include also some of the Gitlab merge descriptions you have to extract them by hand by copy/paste from Gitlab
  • A useful tool for validating your markdown is the editor at http://tmpvar.com/markdown.html
>
>
This creates the file ReleaseNotes/vXrY.md containing the merge request identifier, title, author and description of all MRs merged between the releases vXr(Y-1) and vXrY. The generated file is formatted in Gitlab markdown, according to the file ReleaseNotes/release_notes_template.md. If this file does not exist, the command uses a default one, but it is recommended that you provide one for your project (just copy an existing one from another project and adapt it to your project. Note that you can use labels on Gitlab merge requests to sort the MRs into categories, by adding code snippets like
<!-- SyntaxHighlightingPlugin -->
### New features
{{ section(['new feature']) }}
### Bug fixes
{{ section(['bug fix']) }}
<!-- end SyntaxHighlightingPlugin -->
(in the above example it is assumed you have defined Gitlab labels new feature and bug fix in your Gitlab project).
 
Changed:
<
<
You are ready to commit the changed files to gitlab
>
>
You can then edit the generated file as desired. Once done, you are ready to commit the changed files to gitlab
 
  • First do a git status to double check that you are on the vXrY-release branch, and that you see as modified the files that you have touched in the previous steps
  • execute the following commands
%CODE{"bash"}%
Changed:
<
<
git add CMakeLists.txt ReleaseNotes/vXrY.md MyProjectSys/CMakeLists.txt
>
>
git add CMakeLists.txt ReleaseNotes/vXrY.md
 ## in case of projects based on Gaudi < v28r0, also: git add cmt/project.cmt MyProjectSys/cmt/requirements git commit -m "Documentation and dependencies for vXrY release" git push origin vXrY-release
Line: 65 to 68
 
  • In the release notes of the tag, you can copy/paste the content of the file ReleaseNotes/vXrY.md (hence the interest to use gitlab markdown!)
  • And you are done!
Added:
>
>

Hints

  • The command lb-gen-release-notes is only available in the new LbEnv environment. See LbEnv for instructions on how to set it up
  • In order to extract the release notes from Gitlab, you need to create a Gitlab token: go to https://gitlab.cern.ch/profile/personal_access_tokens and create a personal token with API scope (needs to be done only once). Make a note of the generated token (e.g. dsfadgsdfhfj) and then add it to your shell once per session (export GITLAB_TOKEN="dsfadgsdfhfj")
  • It's a good idea to check the validity of the markdown of the vXrY.md file before you commit it - paste its contents into a comments window in your Gitlab project and check that the format is what you expect and that all hyperlinks are working correctly
 

Preparing a release of the master or someOther branch, including some packages from other projects

From time to time it may be necessary to temporarily include into the release of a project some patches (most often bug fixes) from packages residing in other projects, without waiting for a new release of the entire software stack to pick up the fixes.
Line: 86 to 94
 

Post-processing

In all cases some post-processing is needed to get the tag released and to update the documentation.
Deleted:
<
<
  • Add compatibility information to Ariadne - see here.
 
  • Trigger the release and request deployment - see here.
Changed:
<
<
  • Document the release: the release procedure creates automatically a directory in AFS where one can add documentation about the release in addition to the automatically generated doxygen documentation. The new release appears in a table at the URL http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/myproject/releases (see for example the Brunel table). One can add comments to the table by adding a file called description.html to the AFS directory $LHCBRELEASES/DOC/myproject/releases/vXrY
>
>
  • Document the release: the release procedure creates automatically a directory in AFS where one can add documentation about the release in addition to the automatically generated doxygen documentation. The new release appears in a table at the URL http://cern.ch/lhcbdoc/myproject/releases (see for example the Brunel table). One can add comments to the table by adding a file called description.html to the ES directory $LHCBDOC/myproject/releases/vXrY
 
Deleted:
<
<
-- MarcoCattaneo - 2016-08-08
 \ No newline at end of file
Added:
>
>
-- MarcoCattaneo - 2019-02-13
 \ No newline at end of file

Revision 82017-07-10 - MarcoCattaneo

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

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 gitlab. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Changed:
<
<
Some projects are not yet (as of August 2016) migrated to gitlab. For projects still hosted in SVN please use the procedures documented here

Please note this Wiki (and the procedures it describes) are Work in Progress. Feedback and corrections are welcome

>
>
For reference the old procedure for projects hosted in SVN is documented here
 
Line: 45 to 43
 
<!-- SyntaxHighlightingPlugin -->
git log --name-only --first-parent vXr(Y-1)..  > vXrY.log
<!-- end SyntaxHighlightingPlugin -->
Changed:
<
<
Now edit the file MyProjectSys/doc/release.notes to add information on the release, based on what you extracted into vXrY.log.
>
>
Now create the file ReleaseNote/vXrY.md to add information on the release, based on what you extracted into vXrY.log.
 
  • It is recommended to preserve the formatting used in previous releases; you are encouraged to use the gitlab markdown to link to the merge requests included in the release.
  • Please note that the above command extracts only the git merge messages. If you want to include also some of the Gitlab merge descriptions you have to extract them by hand by copy/paste from Gitlab
Added:
>
>
  You are ready to commit the changed files to gitlab
  • First do a git status to double check that you are on the vXrY-release branch, and that you see as modified the files that you have touched in the previous steps
  • execute the following commands
%CODE{"bash"}%
Changed:
<
<
git add CMakeLists.txt MyProjectSys/doc/release.notes MyProjectSys/CMakeLists.txt
>
>
git add CMakeLists.txt ReleaseNotes/vXrY.md MyProjectSys/CMakeLists.txt
 ## in case of projects based on Gaudi < v28r0, also: git add cmt/project.cmt MyProjectSys/cmt/requirements git commit -m "Documentation and dependencies for vXrY release" git push origin vXrY-release
Line: 63 to 62
 
  • Make a merge request of the vXrY-release branch to the branch that you wish to release (either master or someOther)
  • Merge the request
  • Go to the tags menu and create a new tag, called vXrY on the branch that you wish to release (either master or someOther)
Changed:
<
<
  • In the release notes of the tag, you can copy/paste the changes you made in MyProjectSys/doc/release.notes (hence the interest to use gitlab markdown!)
>
>
  • In the release notes of the tag, you can copy/paste the content of the file ReleaseNotes/vXrY.md (hence the interest to use gitlab markdown!)
 
  • And you are done!

Preparing a release of the master or someOther branch, including some packages from other projects

Line: 81 to 80
  And then follow the same instructions as above to:
  • Update the project version and dependencies
Changed:
<
<
  • Update the release notes
>
>
  • Create the release notes
 
  • Commit the changed files to gitlab
Now go to gitlab. DO NOT make a merge request! Simply tag the branch, using the same instructions as above

Revision 72017-03-29 - MarcoCattaneo

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

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 gitlab. 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
 %ENDCODE% Now edit the file MyProjectSys/doc/release.notes to add information on the release, based on what you extracted into vXrY.log.
  • It is recommended to preserve the formatting used in previous releases; you are encouraged to use the gitlab markdown to link to the merge requests included in the release.
Added:
>
>
  • Please note that the above command extracts only the git merge messages. If you want to include also some of the Gitlab merge descriptions you have to extract them by hand by copy/paste from Gitlab
  You are ready to commit the changed files to gitlab
  • First do a git status to double check that you are on the vXrY-release branch, and that you see as modified the files that you have touched in the previous steps
Line: 54 to 55
 %CODE{"bash"}% git add CMakeLists.txt MyProjectSys/doc/release.notes MyProjectSys/CMakeLists.txt ## in case of projects based on Gaudi < v28r0, also: git add cmt/project.cmt MyProjectSys/cmt/requirements
Changed:
<
<
git commit -m "Prepare vXrY release"
>
>
git commit -m "Documentation and dependencies for vXrY release"
 git push origin vXrY-release %ENDCODE%

Revision 62017-03-27 - MarcoCattaneo

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

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 gitlab. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 52 to 52
 
  • First do a git status to double check that you are on the vXrY-release branch, and that you see as modified the files that you have touched in the previous steps
  • execute the following commands
%CODE{"bash"}%
Changed:
<
<
git add CMakeLists.txt cmt/project.cmt MyProjectSys/doc/release.notes MyProjectSys/CMakeLists.txt MyProjectSys/cmt/requirements
>
>
git add CMakeLists.txt MyProjectSys/doc/release.notes MyProjectSys/CMakeLists.txt ## in case of projects based on Gaudi < v28r0, also: git add cmt/project.cmt MyProjectSys/cmt/requirements
 git commit -m "Prepare vXrY release" git push origin vXrY-release %ENDCODE%

Revision 52016-12-06 - MarcoCattaneo

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

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 gitlab. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 35 to 35
 git checkout -b vXrY-release %ENDCODE% Update the project version and dependencies
Changed:
<
<
  • In each of the files: CMakeLists.txt, MyProjectSys/CMakeLists.txt, MyProjectSys/cmt/requirements, update the project version number to vXrY
  • In each of the files: cmt/project.cmt, CMakeLists.txt, update the project dependencies (i.e. change the version of used projects if they have changed)
>
>
  • In the files CMakeLists.txt, MyProjectSys/CMakeLists.txt, update the project version number to vXrY
  • In the file CMakeLists.txt, update the project dependencies (i.e. change the version of used projects if they have changed)
  • For projects that depend on Gaudi versions prior to v28r0, do the corresponding thing also for the CMT files:
    • In the file MyProjectSys/cmt/requirements, update the project version number to vXrY
    • In the file cmt/project.cmt, update the project dependencies (i.e. change the version of used projects if they have changed)
 Update the release notes
  • It is suggested to use the merge request comments of all the merge requests accepted since the last (e.g. vXr(Y-1)) release. Use the following command to extract them to a file vXrY.log. N.B.: note the trailing ".." of the command, it is important
%CODE{"bash"}%

Revision 42016-09-22 - GloriaCorti

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

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 gitlab. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
Line: 43 to 43
 git log --name-only --first-parent vXr(Y-1).. > vXrY.log %ENDCODE% Now edit the file MyProjectSys/doc/release.notes to add information on the release, based on what you extracted into vXrY.log.
Changed:
<
<
  • It is recommended to preserve the formatting used in previous releases; you are encouraged to use the gitlab markdown to link to the merge requests included in the release.
>
>
  • It is recommended to preserve the formatting used in previous releases; you are encouraged to use the gitlab markdown to link to the merge requests included in the release.
  You are ready to commit the changed files to gitlab
  • First do a git status to double check that you are on the vXrY-release branch, and that you see as modified the files that you have touched in the previous steps

Revision 32016-09-05 - MarcoCattaneo

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

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 gitlab. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group

Revision 22016-08-08 - MarcoCattaneo

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

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 GitLab. 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 gitlab. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group
 
Changed:
<
<
Some project are not yet (as of August 2016) migrated to GitLab. For projects still hosted in SVN please use the procedures documented here
>
>
Some projects are not yet (as of August 2016) migrated to gitlab. For projects still hosted in SVN please use the procedures documented here
 
Changed:
<
<
Please note this Wiki is Work in Progress, feedback and corrections are welcome
>
>
Please note this Wiki (and the procedures it describes) are Work in Progress. Feedback and corrections are welcome
 

Prerequisites

Changed:
<
<
Before making a release, you should ensure that you have merged all merge requests that you would like to include in the released.
>
>
Before making a release, you should ensure that:
  • You have merged all merge requests that you would like to include in the release.
 
  • You need to have "Master" privileges in gitlab for the project you want to release
  • Go to the gitlab home page, click on "Merge Requests" and check that there are no open Merge Requests for the branch that you want to release (or, if there are any, that they are requests that you explicitly want to exclude)
Added:
>
>
  • Your project has been successfully built and tested in the nightlies
    • Note that, depending on the slot configuration, the nightly may or may not pick up pending merge requests.
 
Changed:
<
<

Preparing a release from master branch

This is the most common use case: you wish to tag and release the complete contents of the current master branch of a GitLab project. In the following example we prepare the release of version vXrY of the project Bender
>
>

Preparing a release of the master or someOther branch

These are the most common use cases: you wish to tag and release the complete contents of the current head of the master branch or of someOther branch of a gitlab project. In the following example we prepare the release of version vXrY of the project MyProject
 
Changed:
<
<
1. Open a window on lxplus or other Linux machine with access to gitlab.cern.ch, go to a clean directory, and execute the following commands:
git clone ssh://git@gitlab.cern.ch:7999/lhcb/Bender.git
cd Bender
>
>
Open a window on lxplus or other machine with access to gitlab.cern.ch, go to a clean directory and execute the following commands:
<!-- SyntaxHighlightingPlugin -->
git clone ssh://git@gitlab.cern.ch:7999/lhcb/MyProject.git
cd MyProject
<!-- end SyntaxHighlightingPlugin -->
You are now at the head of your local copy the master branch.
  • If you want to release someOther branch, move to it NOW with the command
<!-- SyntaxHighlightingPlugin -->
git checkout someOther
<!-- end SyntaxHighlightingPlugin -->
You are now at the head of the branch (master or someOther) that you want to release. Create the branch (vXrY-release) in which you will modify the files needed for release and move to it: %CODE{"bash"}%
 git checkout -b vXrY-release
Changed:
<
<
This has created a branch (vXrY-release) from master in which you will modify the files needed for release. 1. Update the project version and dependencies
  • In each of the files: CMakeLists.txt, BenderSys/CMakeLists.txt, BenderSys/cmt/requirements, update the project version number to vXrY
>
>
%ENDCODE% Update the project version and dependencies
  • In each of the files: CMakeLists.txt, MyProjectSys/CMakeLists.txt, MyProjectSys/cmt/requirements, update the project version number to vXrY
 
  • In each of the files: cmt/project.cmt, CMakeLists.txt, update the project dependencies (i.e. change the version of used projects if they have changed)
Changed:
<
<
1. Update the release notes
  • It is suggested to use the merge request comments of all merge requests since the last (e.g. vXr(Y-1)) release. Use the following command to extract them to a file vXrY.log. N.B.: note the trailing ".." of the command, it is important
>
>
Update the release notes
  • It is suggested to use the merge request comments of all the merge requests accepted since the last (e.g. vXr(Y-1)) release. Use the following command to extract them to a file vXrY.log. N.B.: note the trailing ".." of the command, it is important
%CODE{"bash"}%
 git log --name-only --first-parent vXr(Y-1).. > vXrY.log
Changed:
<
<
  • Now edit the file BenderSys/doc/release.notes to add information on the release, based on what you extracted into vXrY.log. It is recommended to preserve the formatting used in previous releases; you are encouraged to use the gitlab markdown to link to the merge requests included in the release.
1. Commit the changed files to gitlab
>
>
%ENDCODE% Now edit the file MyProjectSys/doc/release.notes to add information on the release, based on what you extracted into vXrY.log. *It is recommended to preserve the formatting used in previous releases; you are encouraged to use the gitlab markdown to link to the merge requests included in the release.

You are ready to commit the changed files to gitlab

 
  • First do a git status to double check that you are on the vXrY-release branch, and that you see as modified the files that you have touched in the previous steps
  • execute the following commands
Changed:
<
<
git add CMakeLists.txt cmt/project.cmt BenderSys/doc/release.notes BenderSys/CMakeLists.txt BenderSys/cmt/requirements
>
>
%CODE{"bash"}% git add CMakeLists.txt cmt/project.cmt MyProjectSys/doc/release.notes MyProjectSys/CMakeLists.txt MyProjectSys/cmt/requirements
 git commit -m "Prepare vXrY release" git push origin vXrY-release
Changed:
<
<
1. Now go to gitlab
  • Make a merge request to master branch of the vXrY-release branch
>
>
%ENDCODE%

Now go to gitlab

  • Make a merge request of the vXrY-release branch to the branch that you wish to release (either master or someOther)
 
  • Merge the request
Changed:
<
<
  • Go to the tags menu and create a new tag, called vXrY on the master branch
  • In the release notes of the tag, you can copy/paste the changes you made in BenderSys/doc/release.notes (hence the interest to use gitlab markdown!)
>
>
  • Go to the tags menu and create a new tag, called vXrY on the branch that you wish to release (either master or someOther)
  • In the release notes of the tag, you can copy/paste the changes you made in MyProjectSys/doc/release.notes (hence the interest to use gitlab markdown!)
 
  • And you are done!
Changed:
<
<

Preparing a release from master branch, including some packages from other projects

>
>

Preparing a release of the master or someOther branch, including some packages from other projects

 From time to time it may be necessary to temporarily include into the release of a project some patches (most often bug fixes) from packages residing in other projects, without waiting for a new release of the entire software stack to pick up the fixes.
Changed:
<
<
In the following example we prepare the release of version vXrY of the project Bender, and add a package OtherPackage taking the version that was released with version vNrM of the OtherProject in which it resides
>
>
In the following example we prepare the release of version vXrY of the project MyProject, and add a package OtherPackage taking the version that was released with version vNrM of the OtherProject in which it resides
 
Changed:
<
<
1. Open a window on lxplus or other Linux machine with access to gitlab.cern.ch, go to a clean directory, and execute the following commands:
git clone ssh://git@gitlab.cern.ch:7999/lhcb/Bender.git
cd Bender
git checkout -b vXrY-release
>
>
  • Follow the instructions above to clone a copy of the project and to create a branch (vXrY-release) in which to prepare the files needed for release
  • In this branch, checkout the additional packages to be temporarily added to the release:
%CODE{"bash"}%
 git lb-use OtherProject git lb-checkout OtherProject/vNrM OtherPackage
Changed:
<
<
>
>
%ENDCODE%
 If more patches are required in the release, you can repeat git lb-use and/or lb-checkout for other projects and/or packages as much as needed
Changed:
<
<
1. Follow the instructions above:
>
>
And then follow the same instructions as above to:
 
  • Update the project version and dependencies
  • Update the release notes
  • Commit the changed files to gitlab
Changed:
<
<
1. Go to gitlab DO NOT make a merge request! Simply tag the branch, using the instructions above
>
>
Now go to gitlab. DO NOT make a merge request! Simply tag the branch, using the same instructions as above
 

Post-processing

Changed:
<
<
  • Trigger a release nightly
  • Request deployment
  • Update the DOC pages
  • Update Ariadne
>
>
In all cases some post-processing is needed to get the tag released and to update the documentation.
  • Add compatibility information to Ariadne - see here.
  • Trigger the release and request deployment - see here.
  • Document the release: the release procedure creates automatically a directory in AFS where one can add documentation about the release in addition to the automatically generated doxygen documentation. The new release appears in a table at the URL http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/myproject/releases (see for example the Brunel table). One can add comments to the table by adding a file called description.html to the AFS directory $LHCBRELEASES/DOC/myproject/releases/vXrY
  -- MarcoCattaneo - 2016-08-08 \ No newline at end of file

Revision 12016-08-08 - MarcoCattaneo

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

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 GitLab. Software release procedures are discussed in the lhcb-release-managers E-group, all software release managers should be members of this group

Some project are not yet (as of August 2016) migrated to GitLab. For projects still hosted in SVN please use the procedures documented here

Please note this Wiki is Work in Progress, feedback and corrections are welcome

Prerequisites

Before making a release, you should ensure that you have merged all merge requests that you would like to include in the released.
  • You need to have "Master" privileges in gitlab for the project you want to release
  • Go to the gitlab home page, click on "Merge Requests" and check that there are no open Merge Requests for the branch that you want to release (or, if there are any, that they are requests that you explicitly want to exclude)

Preparing a release from master branch

This is the most common use case: you wish to tag and release the complete contents of the current master branch of a GitLab project. In the following example we prepare the release of version vXrY of the project Bender

1. Open a window on lxplus or other Linux machine with access to gitlab.cern.ch, go to a clean directory, and execute the following commands:

git clone ssh://git@gitlab.cern.ch:7999/lhcb/Bender.git
cd Bender
git checkout -b vXrY-release
This has created a branch (vXrY-release) from master in which you will modify the files needed for release. 1. Update the project version and dependencies
  • In each of the files: CMakeLists.txt, BenderSys/CMakeLists.txt, BenderSys/cmt/requirements, update the project version number to vXrY
  • In each of the files: cmt/project.cmt, CMakeLists.txt, update the project dependencies (i.e. change the version of used projects if they have changed)
1. Update the release notes
  • It is suggested to use the merge request comments of all merge requests since the last (e.g. vXr(Y-1)) release. Use the following command to extract them to a file vXrY.log. N.B.: note the trailing ".." of the command, it is important
git log --name-only --first-parent vXr(Y-1)..  > vXrY.log
  • Now edit the file BenderSys/doc/release.notes to add information on the release, based on what you extracted into vXrY.log. It is recommended to preserve the formatting used in previous releases; you are encouraged to use the gitlab markdown to link to the merge requests included in the release.
1. Commit the changed files to gitlab
  • First do a git status to double check that you are on the vXrY-release branch, and that you see as modified the files that you have touched in the previous steps
  • execute the following commands
git add CMakeLists.txt cmt/project.cmt BenderSys/doc/release.notes BenderSys/CMakeLists.txt BenderSys/cmt/requirements
git commit -m "Prepare vXrY release"
git push origin vXrY-release
1. Now go to gitlab
  • Make a merge request to master branch of the vXrY-release branch
  • Merge the request
  • Go to the tags menu and create a new tag, called vXrY on the master branch
  • In the release notes of the tag, you can copy/paste the changes you made in BenderSys/doc/release.notes (hence the interest to use gitlab markdown!)
  • And you are done!

Preparing a release from master branch, including some packages from other projects

From time to time it may be necessary to temporarily include into the release of a project some patches (most often bug fixes) from packages residing in other projects, without waiting for a new release of the entire software stack to pick up the fixes.

In the following example we prepare the release of version vXrY of the project Bender, and add a package OtherPackage taking the version that was released with version vNrM of the OtherProject in which it resides

1. Open a window on lxplus or other Linux machine with access to gitlab.cern.ch, go to a clean directory, and execute the following commands:

git clone ssh://git@gitlab.cern.ch:7999/lhcb/Bender.git
cd Bender
git checkout -b vXrY-release
git lb-use OtherProject
git lb-checkout OtherProject/vNrM OtherPackage
If more patches are required in the release, you can repeat git lb-use and/or lb-checkout for other projects and/or packages as much as needed 1. Follow the instructions above:
  • Update the project version and dependencies
  • Update the release notes
  • Commit the changed files to gitlab
1. Go to gitlab DO NOT make a merge request! Simply tag the branch, using the instructions above

Post-processing

  • Trigger a release nightly
  • Request deployment
  • Update the DOC pages
  • Update Ariadne

-- MarcoCattaneo - 2016-08-08

 
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