Revision as of 16:11, 21 February 2017

Projects with only Branches

For the most part Devstack and Grenade only have branches, which need to be cut when other projects get stable/* branches during a release.

Devstack

The branch process for Devstack is as follows:

Wait for stable/branch to exist on the bulk of projects in devstack repo
Ask Release Team to create a stable/foo branch
Update .gitreview and stackrc in stable/foo to reference the new branch
Update lib/tempest to hardcode max microversions and extensions

Grenade

The branch process for Grenade is as follows:

Wait for stable/branch to exist on Devstack
Ask Release Team to create a stable/foo branch
Update .gitreview and grenaderc in stable/foo to reference the new branch
1. Example: https://review.openstack.org/129645
Update grenaderc in master to reference the new branch
1. Example: https://review.openstack.org/128959
Update devstack-gate logic to use the new branches
1. Example: https://review.openstack.org/128974/

Project Releases

tempest

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. In addition, the tempest repository contains library interfaces based on https://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/reintegrate-tempest-lib.html So we are releasing new tags in the middle of releases also for new library interfaces. Please see https://github.com/openstack/tempest/releases/tag/12.1.0 as the sample.

The procedure for pushing a new tempest tag is:

Check the format of the existing tags

       $ git tag -n

Check a new reno before tagging. You can see a new reno on the first report

       $ reno report .

You can check it from http://docs.openstack.org/releasenotes/tempest/unreleased.html also

Add a reno for releasing a new tag like https://review.openstack.org/#/c/383442/

Once the version bump is in master you can tag the release and push it to gerrit with:

       $ git tag -s (version number like "12.1.0")
       $ git push gerrit (version number like "12.1.0")

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

If you face the following problem, you need to run "$ git review -s" before pushing:

      $ git push gerrit 14.0.0
      fatal: 'gerrit' does not appear to be a git repository
      fatal: Could not read from remote repository.
      Please make sure you have the correct access rights
      and the repository exists.

tempest-lib

NOTE: tempest-lib itself has been deprecated now, so we never need to release a new tempet-lib anymore

Hacking

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.

The releasing way is the same as Tempest one.

eslint-config-openstack

This project follows the release model of Hacking (above), with a branch for every major.minor release (ex: 0.9.x and 0.8.x). Please refer to the above for process and procedure.

To perform a release, please first install npm on your system. Then, perform the following steps:

   # Check out the most recent master.
   git checkout master; git pull;

   # Ask NPM to update the package version, and tag the release.
   npm version (major|minor|patch)

   # Push the new tag to gerrit
   git push --tags

   # Request for a code review on the new version tag.
   git review

   # Ask NPM to publish the tag to npmjs.com
   # (This step will be deprecated by https://review.openstack.org/#/c/199725/)
   npm publish

@@ Line 1: / Line 1: @@
+= Projects with only Branches =
+For the most part Devstack and Grenade only have branches, which need
+to be cut when other projects get '''stable/*''' branches during a
+release.
+== Devstack ==
+The branch process for Devstack is as follows:
+# Wait for stable/branch to exist on the bulk of projects in devstack repo
+# Ask '''Release Team''' to create a '''stable/foo''' branch
+# Update '''.gitreview''' and '''stackrc''' in '''stable/foo''' to reference the new branch
+# Update '''lib/tempest''' to hardcode max microversions and extensions
+== Grenade ==
+The branch process for Grenade is as follows:
+# Wait for stable/branch to exist on Devstack
+# Ask '''Release Team''' to create a '''stable/foo''' branch
+# Update '''.gitreview''' and '''grenaderc''' in '''stable/foo''' to reference the new branch
+## Example: https://review.openstack.org/129645
+# Update '''grenaderc''' in '''master''' to reference the new branch
+## Example: https://review.openstack.org/128959
+# Update '''devstack-gate''' logic to use the new branches
+## Example: https://review.openstack.org/128974/
 = Project Releases =
@@ Line 4: / Line 32: @@
 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.
+In addition, the tempest repository contains library interfaces based on https://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/reintegrate-tempest-lib.html
+So we are releasing new tags in the middle of releases also for new library interfaces. Please see https://github.com/openstack/tempest/releases/tag/12.1.0 as the sample.
 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
+* Check the format of the existing tags
-* 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
+         $ git tag -n
-this will add the signed tag to the git repo and generate a tarball and store it here: http://tarballs.openstack.org/tempest/
+* Check a new reno before tagging. You can see a new reno on the first report
-== tempest-lib ==
+        $ reno report .
-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"
+You can check it from http://docs.openstack.org/releasenotes/tempest/unreleased.html also
-== Devstack ==
+* Add a reno for releasing a new tag like https://review.openstack.org/#/c/383442/
-DevStack maintains stable branches for all officially supported OpenStack releases.
+* Once the version bump is in master you can tag the release and push it to gerrit with:
-Git repository tags are also maintained for the OpenStack milestones as a quick reference.  These are typically used for jobs that need a relatively recent but unchanging DevStack for testing.  The timing of the milestone tags is not precise but will be within a day or two after the milestone releases are final.  The tags are pushed into Gerrit similar to most projects:
+        $ git tag -s (version number like "12.1.0")
+        $ git push gerrit (version number like "12.1.0")
-    git tag -s <tag> <commit> && git push gerrit <tag>
+this will add the signed tag to the git repo and generate a tarball and store it here: http://tarballs.openstack.org/tempest/
-None of the other side-effects of typical Gerrit repo tagging will happen, no tarball, nothing.  This is only for tagging in the repo.
+If you face the following problem, you need to run "$ git review -s" before pushing:
-=== Things to remember when creating a stable branch ===
+       $ git push gerrit 14.0.0
+       fatal: 'gerrit' does not appear to be a git repository
+       fatal: Could not read from remote repository.
+       Please make sure you have the correct access rights
+       and the repository exists.
-. Hard code the tempest extension list. This is needed with branchless tempest to ensure we are only trying to test new extensions against master. This can be done with the verify-tempest-config script packaged in tempest. lib/tempest has examples on how to use it. See: http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/tempest?h=stable/juno#n303 for an example of a hard coded list.
+== tempest-lib ==
-. Hard code the tempest Compute Maximum Microversion. This is needed with branchless tempest to ensure we are only trying to test new microversions against master. Stable branch must have Maximum microversion same as supported by Nova at that release. See: https://github.com/openstack-dev/devstack/blob/master/lib/tempest#L343-L346. To know maximum microversion supported by Nova at that release see (example of maximum version in liberty): http://docs.openstack.org/developer/nova/api_microversion_history.html#maximum-in-liberty
+'''NOTE: tempest-lib  itself has been deprecated now, so we never need to release a new tempet-lib anymore'''
-== grenade ==
-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.
-# 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.
-# The grenade stable branch needs to be created just like devstack
-# The defaults in the new stable branch need to be updated for example see: https://review.openstack.org/129645
-# 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/
-# 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/
 == Hacking ==
@@ Line 49: / Line 73: @@
 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.
+The releasing way is the same as Tempest one.
 == eslint-config-openstack ==
@@ Line 58: / Line 84: @@
      # Check out the most recent master.
      git checkout master; git pull;
      # Ask NPM to update the package version, and tag the release.
      npm version (major|minor|patch)
      # Push the new tag to gerrit
      git push --tags
      # Request for a code review on the new version tag.
      git review
      # Ask NPM to publish the tag to npmjs.com
      # (This step will be deprecated by https://review.openstack.org/#/c/199725/)
      npm publish

Difference between revisions of "QA/releases"