Jump to: navigation, search

ReleaseTeam/How To Release

Revision as of 00:00, 1 January 1970 by (talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Raw notes for release managers, or release monkeys if need be.

<<TableOfContents()>>

We have two kinds of projects when it comes to release management:

  • External projects (Swift) release milestones as complete versions with their own versioning scheme (1.4.0), and the coordinated release just takes the latest milestone for integration in the OpenStack common release.
  • Internal projects (Glance, Nova) deliver milestones with a code name (diablo-1), and the coordinated release corresponds to their major release every 6 months (2011.3)

This leads to two slightly different processes.

Release process

External milestone release

(example: release Swift 1.4.0)

When trunk is ready for a milestone:

  • In trunk: push change in swift/init.py, change from 1.4.0 to 1.4.1 (leave False)
  • In milestone-proposed, merge from the last revision of trunk before the above change
  • Call for testing on milestone-proposed once it's built

Select bugfixes should be pushed to milestone-proposed if need be. When milestone-proposed is ready for release:

  • In milestone-proposed: push change in swift/init.py, change from False to True (leave 1.4.0)
  • In milestone-proposed: Tag release: 1.4.0 (see howto below)
  • Release "1.4.0" with resulting tarball (see howto below)
    • Description: Swift 1.4.0 release

Internal milestone release

(example: release Nova diablo-1)

  • Merge the translations branch ?
    • Nova: Propose merge of lp:nova/translations into lp:nova
    • Glance, Swift: noop

When trunk is ready for a milestone:

  • Bump milestone in Jenkins (common-bump-milestone) to: d2 for trunk, d1 for milestone-proposed.
  • In milestone-proposed, merge from the last revision of trunk
  • Call for testing on milestone-proposed once it's built

Select bugfixes should be pushed to milestone-proposed if need be. When milestone-proposed is ready for release:

  • In milestone-proposed: Tag release: 2011.3-d1 (see howto below)
  • Release "diablo-1" with resulting tarball (see howto below)
    • Description: Nova "diablo-1" milestone

Internal final release

(example: release Nova 2011.3)

  • Merge the translations branch: /!\ This requires core team presence at crunch time
    • Nova: Propose merge of lp:nova/translations into lp:nova
    • Glance, Swift: noop

When trunk is ready for a RC:

  • Bump milestone in Jenkins (common-bump-milestone) to: e1 for trunk, rc for milestone-proposed
  • In trunk: push change in nova/version.py, change from 2011.3 to 2011.4 (leave False)
  • In milestone-proposed, merge from the last revision of trunk before above change
  • Call for testing on milestone-proposed once it's built

Select bugfixes should be pushed to milestone-proposed if need be. When milestone-proposed is ready for release:

  • In milestone-proposed: push change in nova/version.py, change from False to True (leave 2011.3)
  • In milestone-proposed: Tag release: 2011.3 (see howto below)
  • Release "2011.3" with resulting tarball (see howto below)
    • Description: Nova 2011.3 ("diablo") release

After release

  • Branch stable release /!\ more details needed
  • Link trunk to next release /!\ more details needed
  • Push new versioning to trunk:
    • Nova, Glance: edit version.py to bump NOVA_VERSION and set FINAL = False
    • Swift: edit swift/<u>init</u>.py (1.3.0 -> 1.4-dev)
  • Target all bugs FixCommitted bugs to release and mark them FixReleased
  • Create milestones for the next release:
    • CODENAME-gamma
    • CODENAME-rc
    • VERSION (codename CODENAME)

Howtos

Tag

  • Go to Jenkins, nova job, click on Tags
  • Set the checkbox for the first in the list, set tag, click OK

Release MILESTONE with BZRREVISION as MVERSION

  • Download http://PROJECT.openstack.org/tarballs/PROJECT-VERSION~BZRREVISION.tar.gz
  • Sanity-check tarball contents: tar tzf PROJECT-VERSION~BZRREVISION.tar.gz
  • Calculate MD5: md5sum PROJECT-VERSION~BZRREVISION.tar.gz
  • Rename file: mv PROJECT-VERSION~BZRREVISION.tar.gz PROJECT-MVERSION.tar.gz
  • Sign file: gpg --armor --sign --detach-sig PROJECT-MVERSION.tar.gz
  • Mark milestone as released in Launchpad
  • Add a download file
    • Click "Add a download file" on the milestone page
    • Set description accordingly
    • Point to tarball (PROJECT-MVERSION.tar.gz) and signature (PROJECT-MVERSION.tar.gz.asc)
    • File content type: "Code release tarball"
  • Doublecheck md5sum
    • Click on "md5" at the download level and compare with the one previously generated

Push a release to PyPI

Prerequisites:

  • Contact one of the existing PyPI maintainers for Glance (JayPipes, EwanMellor or MontyTaylor) and get them to add you to the release admins.
  • Create a login/password and set your PGP key on your PyPI account details area

Process:

  • Upload PKG-INFO from release tarball to set release details
  • In "Files", Upload "source" tarball, any python version, with signature.

Open new branch

  • Create stable branch (for the just-released SERIES)
    • ssh to jenkins box
    • sudo su - jenkins
    • mkdir tmp && cd tmp
    • bzr branch lp:PROJECT
    • cd PROJECT
    • bzr push lp:~openstack-hudson/PROJECT/SERIES
  • Point newly-created series to ~hudson-openstack/PROJECT/trunk
  • Point just-released series to newly-created ~openstack-hudson/PROJECT/SERIES
  • Switch branches
Retrieved from "https://wiki.openstack.org/w/index.php?title=ReleaseTeam/How_To_Release&oldid=10937"