Difference between revisions of "QA/releases"
(→Things to remember when creating a stable branch) |
|||
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 = | = Project Releases = | ||
Line 18: | Line 46: | ||
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" | 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" | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Hacking == | == Hacking == | ||
Line 58: | Line 61: | ||
# Check out the most recent master. | # Check out the most recent master. | ||
git checkout master; git pull; | git checkout master; git pull; | ||
− | + | ||
# Ask NPM to update the package version, and tag the release. | # Ask NPM to update the package version, and tag the release. | ||
npm version (major|minor|patch) | npm version (major|minor|patch) | ||
− | + | ||
# Push the new tag to gerrit | # Push the new tag to gerrit | ||
git push --tags | git push --tags | ||
− | + | ||
# Request for a code review on the new version tag. | # Request for a code review on the new version tag. | ||
git review | git review | ||
− | + | ||
# Ask NPM to publish the tag to npmjs.com | # Ask NPM to publish the tag to npmjs.com | ||
# (This step will be deprecated by https://review.openstack.org/#/c/199725/) | # (This step will be deprecated by https://review.openstack.org/#/c/199725/) | ||
npm publish | npm publish |
Revision as of 13:16, 22 March 2016
Contents
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
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.
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/
tempest-lib
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"
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.
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