Page tree
Skip to end of metadata
Go to start of metadata

OPNFV Process to prepare the release

This page describes the steps in CI to prepare the OPNFV releases.

Colorado Release

Colorado release preparation reaches its final phase with milestone 9, when the stable branch is created.

Stable Branch Creation

Milestone 9 is the start of the stable branch creation window.  The window will open on Monday, August 15.  The window will close on Monday, August 22 at 12 p.m. (PST).

TheStable branch creation will use the following process:

  1. PTLs will file a help-desk ticket with LF when their project is ready to be branched and before the window closes.  The help-desk ticket should include the following:
    1. Project name and repo name
    2. Commit ID or tag on master where the branch should be created
    3. If no commit ID or tag is specified, then the branch will be created using HEAD
  2. LF will create the branch and close the ticket
  3. For projects that have not submitted a ticket requesting a branch by the time the window has closed, then LF will create a branch based on HEAD.

Using Stable Branch

Code freeze is achieved for a project when the stable branch is created and the stable branch policy is followed as described below. 

After stable branch creation, bug fixing for Colorado will be done according to the stable-branch process as described at Stablebranch. Briefly, all fixes must be cherrypicked from master to stable/colorado. Parallel development on master branch is now possible without endangering the stable branch.

Steps to take for Finalizing the Colorado Release

  • PTLs tag corresponding/identified revisions/SHA1s on stable/colorado branch in respective repos
  • LF is notified regarding the final release artifacts
  • LF copies the final release artifacts and documents to Colorado release storage
  • LF creates links to released artifacts and documents on download pages: www.opnfv.org/software/
  • Marketing team sends release announcement mail

Tagging the final release

PTLs of Colorado participating projects are responsible of

  • Identifying the SHA1 to apply the tag on and release
  • Tagging the SHA1 with the release tag, colorado.1.0
  • If valid, tagging the Docker images with the release tag, colorado.1.0
  • Identifying the exact versions of the artifacts (ISO, RPM, documents, etc. if valid) with the help from documentation, infra, and LF.
  • Making sure the correct artifacts are linked/referred on the release page.

Colorado Release Tag and Branch Name

<RELEASE TAG> colorado.1.0

<BRANCH NAME> stable/colorado

git tagging instructions

PTLs of participating projects will apply the tags in respective repos.

SHA1s to Apply Tags on for SR1

SHA1s of the repos are identified by PTLs. If the project is integrated to other projects (such as installer projects) it is important to communicate with these projects as well.

To select the SHA1 to apply the tag for, you can use Gerrit web interface or the git commands as listed below.

  • Using Gerrit Web Interface:
  • Using Git command
    • git checkout <BRANCH NAME>
    • git log --graph

Tagging

  • git fetch origin
  • git checkout <BRANCH NAME>
  • git checkout <SHA1>
  • git tag -am "<RELEASE TAG>" <RELEASE TAG>
  • git push origin <RELEASE TAG>

If you get error like ! [remote rejected] colorado.1.0 -> colorado.1.0 (prohibited by Gerrit) This is because you are not the author of the commit being tagged. Send an email to opnfv-helpdesk@rt.linuxfoundation.org and LF will add forge rights to refs/tags/* on your repo.

Please contact aricg and/or other Octopus members on #opnfv-octopus channel if you experience any issues.

Brahmaputra Release

see here for reference the instructions for Brahmaputra release. 

PTLs of Brahmaputra participating projects are responsible of

  • Identifying the SHA1 to apply the tag on and release
  • Tagging the SHA1 with the release tag, brahmaputra.1.0
  • If valid, tagging the Docker images with the release tag, brahmaputra.1.0
  • Identifying the exact versions of the artifacts (ISO, RPM, documents, etc. if valid) with the help from documentation, infra, and LF.
  • Making sure the correct artifacts are linked/referred on release page.

Steps to take for Brahmaputra Release

  • PTLs tag corresponding/identified revisions/SHA1s on stable/brahmaputra branch in respective repos
  • LF is notified regarding the final release artifacts
  • LF copies the final release artifacts and documents to Brahmaputra release storage
  • LF creates links to released artifacts and documents on download pages: www.opnfv.org/software/<tbd>
  • Marketing team send release announcement mail

Brahmaputra Release Tag

brahmaputra.1.0

Storage Locations for Final Brahmaputra Artifacts

TBD

Brahmaputra git tagging instructions

PTLs of Brahmaputra participating projects will apply the tags in respective repos.

SHA1s to Apply Tags on for SR1

SHA1s of the repos are identified by PTLs. If the project is integrated to other projects (such as installer projects) it is important to communicate with these projects as well.

To select the SHA1 to apply the tag for, you can use Gerrit web interface or the git commands as listed below.

  • Using Gerrit Web Interface:
  • Using Git command
    • git checkout stable/brahmaputra
    • git log --graph

Tagging

  • git fetch origin
  • git checkout stable/brahmaputra
  • git checkout <SHA1>
  • git tag -am "brahmaputra.1.0" brahmaputra.1.0
  • git push origin brahmaputra.1.0

If you get the error
! [remote rejected] brahmaputra.1.0 -> brahmaputra.1.0 (prohibited by Gerrit)
This is because you are not the author of the commit being tagged. email helpdesk and I will add forge rights to refs/tags/* on your repo.

Please contact aricg and/or other Octopus members on #opnfv-octopus channel if you experience any issues.

  • No labels

1 Comment

  1. Creation of the stable branch is to freeze the code. So code freeze is reached when the stable branch is there and stable branch policy is followed.

    Stable branch must be stable. So fixes have to be tested on master before they are cherrypicked to stable.

    Let's not change the process at late stage.