Jump to: navigation, search


< QA
Revision as of 09:17, 3 December 2014 by Jogo (talk | contribs) (Hacking)

Project Releases


With the start of branchless tempest there are no long any tempest releases, but instead incremental tags for each OpenStack release milestones. The tag should be incremented to coincide with either a new OpenStack release, or the EOL of a supported stable branch. For example, the tempest-2 tag was added at the Juno release and was used to mark adding support for the Kilo release. The next tag tempest-3 will be used to either signify the start of L development or the EOL of icehouse, whichever occurs first.

The procedure for pushing a new tempest tag is:

  • Identify the commit you would like to tag as the next tag and write down the sha1. This can just be the current HEAD commit but make sure you use use the sha1 for the commit from the log and not some other shorthand as that will likely change
  • Push the version bump in setup.cfg. For example, see: http://git.openstack.org/cgit/openstack/tempest/commit/?id=66d8831d173cd4713bff8875bd516ad132db9070 this step must occur before you push the tag or you risk breaking pbr's semver check
  • Once the version bump is in master you can tag the release and push it to gerrit with:
       git tag -s 3  $(sha1_to_tag) && git push gerrit 3

this will add the signed tag to the git repo and generate a tarball and store it here: http://tarballs.openstack.org/tempest/


The mechanics for pushing a new tempest-lib release are basically the same (pushing a tag to gerrit) however the operations that get performed during this process are different. Also tempest-lib conforms to more traditional semver scheme and adheres to the mantra "release early, release often"


Release Branch Procedure:


Just like devstack grenade doesn't have publish releases or tags, but at each OpenStack release a stable branch needs to be created. Unlike grenade however there are also some updates that need to be made in repo to handle the new branch names for upgrading.

  1. The new devstack stable branch needs to be created. Without a stable devstack branch grenade won't have anything new to update from for master.
  2. The grenade stable branch needs to be created just like devstack
  3. The defaults in the new stable branch need to be updated for example see: https://review.openstack.org/129645
  4. Update the grenade master branch to upgrade from the newly created release to master and update the name of the working dev release. For example see: https://review.openstack.org/#/c/128959/
  5. At this point devstack-gate needs to be updated so that the branches being update from and to are correct for all the gating jobs. For example see: https://review.openstack.org/#/c/128974/


Versioning: http://docs.openstack.org/developer/hacking/readme.html#versioning

Hacking has a branch for every major.minor release. For example: 0.9.x and 0.8.x. The process for cutting a new major or minor release involves creating a new branch and pushing a tag (major.minor.0). At that point patches that fit the versioning requirements can be backported to the stable branch for maintenance releases.