Difference between revisions of "Oslo/ReleaseProcess"
(Created page with "= Oslo Library Release Process = See Oslo/VersioningPolicy for guidelines for choosing version numbers. Update a sandbox and create a signed tag for the release: $ gi...") |
(→Oslo Library Release Process) |
||
| Line 1: | Line 1: | ||
= Oslo Library Release Process = | = Oslo Library Release Process = | ||
| + | |||
| + | == Version Numbers == | ||
See [[Oslo/VersioningPolicy]] for guidelines for choosing version numbers. | See [[Oslo/VersioningPolicy]] for guidelines for choosing version numbers. | ||
| − | + | == Post-Release Tracking == | |
| + | |||
| + | Because Oslo libraries tend to generate releases far more often than the integrated projects, we use "post-release" tracking rather than major milestone predictive tracking. Release series are named after the current development cycle code name, using all lower case letters. Each library should also have a single open "next-$series" milestone within the series. Active work is placed in the milestone, and the milestone is renamed as part of the release process to indicate that the completed work was done in the given release. | ||
| + | |||
| + | For example, oslo.log has a "kilo" series and a "next-kilo" milestone. Blueprints and bugs are added to "next-kilo" as work begins. When release 0.1.0 of oslo.log is tagged, the "next-kilo" milestone is renamed to "0.1.0" and a new "next-kilo" milestone is created. Any blueprints or bugs *not* completed as part of the 0.1.0 release is moved to the new milestone and work continues. | ||
| + | |||
| + | The oslo-incubator uses major milestone tracking ("kilo-1", "kilo-2", etc.) because it is not technically released and because we use the oslo-incubator project for blueprints and specs that are not related to a single library. | ||
| + | |||
| + | == Installing Release Tools == | ||
| + | |||
| + | The release management team has created some tools to help manage our releases. To install the tools, check out a copy of the openstack-infra/release-tools git repository, create a virtualenv, and install the dependencies: | ||
| + | |||
| + | $ git clone git://git.openstack.org/openstack-infra/release-tools | ||
| + | $ cd release-tools | ||
| + | $ virtualenv .venv | ||
| + | $ source .venv/bin/activate | ||
| + | $ pip install -r requirements.txt | ||
| + | |||
| + | == Setting Up GPG == | ||
| + | |||
| + | OpenStack releases rely on GPG-signed tags in the git repository. You will need a GPG key configured on the system where you are going to tag releases. It is good to have your key signed by other members of the community to establish a web-of-trust. There are usually in-person meetings at the summits and mid-cycle meetups to take care of key signings. | ||
| + | |||
| + | == Setting up Launchpad == | ||
| + | |||
| + | The release tool connects to launchpad, which requires oauth authorization. Setting this up usually requires a web browser, and some users have experience trouble with console browsers such as lynx. You may, therefore, want to run the release scripts on your local system where a regular GUI browser is available, instead of on a remote server where only the terminal is available to you. | ||
| + | |||
| + | == Setting up Gerrit Permissions == | ||
| + | |||
| + | After the release tool checks out the code repository specified and creates the signed tag, it pushes the tag up to gerrit. You need special permissions to push tags to gerrit, so make sure you are in the release team for the project you are trying to release. Another member of the same gerrit release team, or the infra team, can help you set this up. | ||
| + | |||
| + | == Releasing a Library == | ||
| + | |||
| + | Use the oslo_release.sh script to tag a release and update launchpad. | ||
| + | |||
| + | $ ./oslo_release.sh | ||
| + | Usage: ./oslo_release.sh series version SHA project | ||
| + | Example: ./oslo_release.sh juno 1.0.0 HEAD oslo.rootwrap | ||
| + | |||
| + | After the repository is tagged, the release tool updates all of the closed bugs for the project, ensuring they are in the next-$series milestone. It then renames that milestone to the version number you have specified, making release notes and tracking easier. | ||
| + | |||
| + | At that point the script prints a message like "Fix any leftover bugs manually and press key to continue...". STOP HERE AND GO LOOK AT LAUNCHPAD. | ||
| + | |||
| + | First, create a new next-$series milestone by clicking the "Create milestone" link on the series page. | ||
| + | |||
| + | Next, if there are any blueprints or bugs in the version milestone that are *not* completed, move them to next-$series. | ||
| + | |||
| + | Only when this is done, go back to the terminal and press return to continue the process. At this point, the script closes the old milestone so no new items can be added to it. | ||
| + | |||
| + | == Send Release Notes == | ||
| + | |||
| + | We generate release notes for library releases directly from the git logs, so refresh your local sandbox: | ||
$ git pull | $ git pull | ||
| − | |||
Get the changes in the release: | Get the changes in the release: | ||
Revision as of 15:20, 14 November 2014
Contents
Oslo Library Release Process
Version Numbers
See Oslo/VersioningPolicy for guidelines for choosing version numbers.
Post-Release Tracking
Because Oslo libraries tend to generate releases far more often than the integrated projects, we use "post-release" tracking rather than major milestone predictive tracking. Release series are named after the current development cycle code name, using all lower case letters. Each library should also have a single open "next-$series" milestone within the series. Active work is placed in the milestone, and the milestone is renamed as part of the release process to indicate that the completed work was done in the given release.
For example, oslo.log has a "kilo" series and a "next-kilo" milestone. Blueprints and bugs are added to "next-kilo" as work begins. When release 0.1.0 of oslo.log is tagged, the "next-kilo" milestone is renamed to "0.1.0" and a new "next-kilo" milestone is created. Any blueprints or bugs *not* completed as part of the 0.1.0 release is moved to the new milestone and work continues.
The oslo-incubator uses major milestone tracking ("kilo-1", "kilo-2", etc.) because it is not technically released and because we use the oslo-incubator project for blueprints and specs that are not related to a single library.
Installing Release Tools
The release management team has created some tools to help manage our releases. To install the tools, check out a copy of the openstack-infra/release-tools git repository, create a virtualenv, and install the dependencies:
$ git clone git://git.openstack.org/openstack-infra/release-tools $ cd release-tools $ virtualenv .venv $ source .venv/bin/activate $ pip install -r requirements.txt
Setting Up GPG
OpenStack releases rely on GPG-signed tags in the git repository. You will need a GPG key configured on the system where you are going to tag releases. It is good to have your key signed by other members of the community to establish a web-of-trust. There are usually in-person meetings at the summits and mid-cycle meetups to take care of key signings.
Setting up Launchpad
The release tool connects to launchpad, which requires oauth authorization. Setting this up usually requires a web browser, and some users have experience trouble with console browsers such as lynx. You may, therefore, want to run the release scripts on your local system where a regular GUI browser is available, instead of on a remote server where only the terminal is available to you.
Setting up Gerrit Permissions
After the release tool checks out the code repository specified and creates the signed tag, it pushes the tag up to gerrit. You need special permissions to push tags to gerrit, so make sure you are in the release team for the project you are trying to release. Another member of the same gerrit release team, or the infra team, can help you set this up.
Releasing a Library
Use the oslo_release.sh script to tag a release and update launchpad.
$ ./oslo_release.sh Usage: ./oslo_release.sh series version SHA project Example: ./oslo_release.sh juno 1.0.0 HEAD oslo.rootwrap
After the repository is tagged, the release tool updates all of the closed bugs for the project, ensuring they are in the next-$series milestone. It then renames that milestone to the version number you have specified, making release notes and tracking easier.
At that point the script prints a message like "Fix any leftover bugs manually and press key to continue...". STOP HERE AND GO LOOK AT LAUNCHPAD.
First, create a new next-$series milestone by clicking the "Create milestone" link on the series page.
Next, if there are any blueprints or bugs in the version milestone that are *not* completed, move them to next-$series.
Only when this is done, go back to the terminal and press return to continue the process. At this point, the script closes the old milestone so no new items can be added to it.
Send Release Notes
We generate release notes for library releases directly from the git logs, so refresh your local sandbox:
$ git pull
Get the changes in the release:
$ git log --abbrev-commit --pretty=oneline --no-merges $prevrel..$relnum
Email the details to the openstack-dev mailing list, for example:
The Oslo team is pleased to announce the release of stevedore 1.0.0.0a1, the first pre-release in the 1.0.0 series for stevedore during the Juno cycle. stevedore provides access pattern abstractions on top of setuptools entry points, and is used for dynamically loading plugins and drivers. This release includes: $ git log --abbrev-commit --pretty=oneline 0.15..1.0.0.0a1 d37b47f Merge "Updated from global requirements" bc2d08a Updated from global requirements e8e9ca1 Fix incorrect image reference in documentation d39ef75 Fix requirement handling in tox 65fc0d2 Merge "use six.add_metaclass" 58ff35c Updated from global requirements d9d11fc use six.add_metaclass a0721b4 Merge "fix link to entry point docs" ff1f0fd Merge "Updated from global requirements" 53b4231 Merge "Add doc requirements to venv environ" d5fb7a8 Updated from global requirements 3668de2 driver: raise by default on import failure 6a37e5f Add doc requirements to venv environ cde4b1d Merge "Import run_cross_tests.sh from oslo-incubator" f2af694 Import run_cross_tests.sh from oslo-incubator 9ae8bef fix link to entry point docs For more details about the 1.0.0 release series, see https://etherpad.openstack.org/p/stevedore-1.0.0 Please report problems using the oslo bug tracker https://bugs.launchpad.net/oslo
