Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: master -> main

...

  1. Ensure that you are working on the correct branch.  The CloudStack community has adopted a branch-before-release strategy for release branches.
  2. Confirm that the information in README.md is current
  3. Confirm that the information in INSTALL.md is current
  4. Update the CHANGES file with the critical changes introduced in the release (Be sure to highlight any changes the break backward compatibility)
  5. Remove "version has not been released" warnings from the CHANGES file
  6. Ensure that the CHANGES file in your release branch is synced with the version in the master main branch (which may have a future release already in it)
  7. Confirm that there is a Jenkins build process for the release branch and that all associated jobs are succeeding.
  8. You'll need your GPG public key to be added to the CloudStack KEYS file (see Appendix A at the end of the article on how to do that).

...

Then run the source build script (Replacing the parameters: X.Y.Z.0=your official version number for the release; X.Y=the branch (can be mastermain) that the release is coming from; CCCC=the GPG Key to sign both the artifacts and the git tag with):

...

Code Block
languagebash
$ git checkout X.Y-RC$TIMESTAMP # checkout the RC branch
$ git tag X.Y.Z.0 # the tag has already been created by build_asf.sh
$ git push origin X.Y.Z.0 # push the tag to origin

# if Z=0 / i.e. NEW release (X.Y.0.0)
  # Rename the RC branch and set the next POMs version in this new branch
  $ git branch -m X.Y-RC$TIMESTAMP X.Y
  $ git push -u origin X.Y
  $ bash tools/build/setnextversion.sh -b X.Y -v X.Y.1.0-SNAPSHOT -s /root/cloudstack # replace with local working directory
  $ grep -r "X.Y.0.0" . # doublecheck by grepping for the older POM version - should return a few git refs and comments - not the POMs/code - and if all good push
  $ git push origin X.Y
  # Merge the new branch into the mastermain AND set the nextversions in the mastermain branch
  $ git checkout mastermain
  $ git pull
  $ git merge X.Y
  $ bash tools/build/setnextversion.sh -b mastermain -v X.Y+1.0.0-SNAPSHOT -s /root/cloudstack # replace with local working directory
  $ grep -r "X.Y.1.0" . # doublecheck by grepping for the older POM version - should return a few git refs and comments - not the POMs/code - and if all good push
  $ git push origin mastermain

# else Z!=0 (LTS maintenance release, X.Y.Z.0)
  # Merge the RC branch into the release branch AND set the nextversions in the current X.Y branch
  $ git checkout X.Y
  $ git pull
  $ git merge X.Y-RC$TIMESTAMP
  $ bash tools/build/setnextversion.sh -b X.Y -v X.Y.Z+1.0-SNAPSHOT -s /root/cloudstack # replace with local working directory
  $ grep -r "X.Y.Z.0" . # doublecheck by grepping for the older POM version - should return a few git refs and comments - not the POMs/code - and if all good push
  $ git push origin X.Y

# end of IF/ELSE block, delete older RC branches (repeat for all RC branches)
  $ git branch -d X.Y-RC$TIMESTAMP # delete the RC branch locally
  $ git push origin :X.Y-RC$TIMESTAMP # deletes the RC branch on origin

...

Code Block
languagebash
Example for 4.14.0.0 **new** release

$ git checkout 4.14.0.0-RC20200511T1503 # checkout the RC branch
$ git tag 4.14.0.0 # the tag has already been created by build_asf.sh
$ git push origin 4.14.0.0 # push the tag to origin
# Rename the RC branch and set the next version in this new branch
$ git branch -m 4.14.0.0-RC20200511T1503 4.14
$ git push -u origin 4.14
$ bash tools/build/setnextversion.sh -b 4.14 -v 4.14.1.0-SNAPSHOT -s /root/cloudstack # replace with local working directory
$ grep -r "4.14.0.0" . # doublecheck by grepping for the older POMs version - should return a few git refs and comments - not the POMs/code - and if all good push
$ git push origin 4.14
# Merge the new branch into the mastermain AND set the nextversions in the mastermain branch
$ git checkout mastermain
$ git pull
$ git merge 4.14
$ bash tools/build/setnextversion.sh -b mastermain -v 4.15.0.0-SNAPSHOT -s /root/cloudstack #replace with local working directory
$ grep -r "4.14.1.0" . # doublecheck by grepping for the older POM version - should return a few git refs and comments - not the POMs/code - and if all good push
$ git push origin mastermain
# delete older RC branches (repeat for all RC branches)
$ git branch -d 4.14.0.0-RC20200511T1503 # delete the RC branch locally
$ git push origin :4.14.0.0-RC20200511T1503 # deletes the RC branch on origin

Example for 4.13.1.0 **maintenance** release

$ git checkout 4.13.1.0-RC20200423T1917 # checkout the RC branch
$ git tag 4.13.1.0 # the tag has already been created by build_asf.sh
$ git push origin 4.13.1.0 # push the tag to origin
# Merge 4.13.1.0-RC20200423T1917 into the 4.13 AND set the nextversions in the current/4.13 branch
$ git checkout 4.13
$ git pull
$ git merge 4.13.1.0-RC20200423T1917
$ bash tools/build/setnextversion.sh -b 4.13 -v 4.13.2.0-SNAPSHOT -s /root/cloudstack #replace with local working directory
$ grep -r "4.13.1.0" . # doublecheck by grepping for the older POM version - should return a few git refs and comments - not the POMs/code - and if all good push
$ git push origin 4.13
# delete older RC branches (repeat for all RC branches) - BUT better NOT delete the voted RC branch before generating the API doc - see below note on updating http://cloudstack.apache.org/
$ git branch -d 4.13.1.0-RC20200423T1917 # delete the RC branch locally
$ git push origin :4.13.1.0-RC20200423T1917 # deletes the RC branch on origin

...

...

...

  • for a new release (i.e. new one being 4.14.0.0, while the current is 4.13.x), make sure to create a new branch (4.14 in this example) out of the Master main branch (where all the documentation updates are previously done)
    • Set the new git tag (i.e. "4.14.0.0") to point to the last commit in the new branch (4.14 in this example) - tags are used by Read The Docs to display different documentation versions
    • From the Read The Docs admin section, configure the "Latest" version to point to the new tag ("4.14.0.0") and also add/activate/build the new version explicitly (from tag "4.14.0.0")
    • Additionally, merge back the previously created branch (4.14) to the Master main branch and consider editing the main variable files ('source/conf.py' and 'source/_global.rst) in the Master main branch - this is optional and will have to be done for the future release at some point
  • for the maintenance release (i.e. new one being 4.13.1.0, while the current one is 4.13.0.0), set the new git tag ("4.13.1.0") to the last commit id in the current (4.13) documentation branch (where all the documentation updates are previously done)
    • From the Read The Docs admin section, configure the "Latest" version to point to the new git tag (4.13.1.0) and also add/activate/build the new version explicitly (from tag "4.13.1.0")
  • Verify the new documentation is visible (i.e.https://docs.cloudstack.apache.org/en/latest, https://docs.cloudstack.apache.org/en/4.13.1.0/, https://docs.cloudstack.apache.org/en/4.14.0.0/)

...

The downloads page at http://cloudstack.apache.org/downloads.html must be updated - this involves updating the /data/cloudstack.yaml in http://github.com/apache/cloudstack-www and then building the website (build.sh).
Also, API docs need to be updated if this is a new release (i.e. not maintenance release) - this is done by adding the generated API docs to the https://github.com/apache/cloudstack-www/tree/mastermain/source/api/ folder. (i.e. apidocs are generating as part of "mvn -Pdeveloper -Dnoredist clean install -pl :cloud-apidoc" when running this script - and will be located in the "tools/apidoc/" folder) 

...