Jump to: navigation, search

Difference between revisions of "ReleaseTeam/How To Release"

 
(57 intermediate revisions by 5 users not shown)
Line 1: Line 1:
__NOTOC__
+
{{ caution|http://git.openstack.org/cgit/openstack-infra/release-tools/tree/README.rst|Information here is obsolete.You should read instead: }}
<!-- ## page was renamed from [[HowToRelease]] -->
 
Raw notes for release managers, or release monkeys if need be.
 
  
<<[[TableOfContents]]()>>
+
You can find all tools mentioned here in the [http://git.openstack.org/cgit/openstack-infra/release-tools openstack-infra/release-tools] repository.
  
First, read [[BranchModel]].
+
__TOC__
  
Second: release Swift first, Glance next, and Nova last.
+
== Development milestone publication ==
 +
 
 +
<pre><nowiki>
 +
PROJECT=nova
 +
MILESTONE=juno-3
 +
</nowiki></pre>
 +
 
 +
 
 +
==== Pre-flight checks ====
 +
 
 +
 
 +
'''Missing files check''' (for all integrated projects doing the milestone)
 +
<pre><nowiki>
 +
./repo_tarball_diff.sh $PROJECT master
 +
</nowiki></pre>
 +
 
 +
 
 +
==== Milestone tag/publication (between Tuesday and Thursday) ====
 +
 
 +
All the integrated projects, as well as oslo-incubator and oslo.messaging, need to follow this process sometimes during the milestone publication window.
 +
 
 +
NB: The milestone.sh script special-cases oslo-incubator (where no tarball is published) and oslo.messaging (where no tag is pushed and no tarball is published) so you can just run the same commands with them.
  
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.
+
'''Get PTL signoff''' (for all except oslo.messaging)
* '''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)
+
* PTL confirms SHA for tag
  
This leads to two slightly different processes.
 
  
= Release process =
+
'''Deferring blueprints and bugs'''
 +
* Move all incomplete blueprints to the next milestone ($MILESTONE should all be 'Implemented')
 +
* Move all incomplete bugs to the next milestone ($MILESTONE should all be 'Fix Committed'). You can use the following script:
  
== External release (Swift) ==
+
<pre><nowiki>
 +
./process_bugs.py $PROJECT --milestone $MILESTONE --settarget $NEXTMILESTONE
 +
</nowiki></pre>
  
  
 +
'''Tag, wait for tarball build, process FixCommitted bugs, check similarities and upload (if applicable)'''
 
<pre><nowiki>
 
<pre><nowiki>
VER=1.4.0    # The version you want to release
+
./milestone.sh $MILESTONE $SHA $PROJECT
 
</nowiki></pre>
 
</nowiki></pre>
  
  
When trunk is ready for a milestone, get the swift-core signoff by doing:
+
NB: for oslo.messaging $SHA is not used for tagging and is therefore ignored.
 +
 
 +
 
 +
==== When all projects are done ====
 +
 
 +
'''Announce milestone'''
 +
* Email to openstack general ML
 +
* Twitter
 +
 
 +
 
 +
== Swift intermediary releases ==
  
 
<pre><nowiki>
 
<pre><nowiki>
# In master swift/__init__.py, propose change from $VER to $VER+1 (leave 'False')
+
PROJECT=swift
#No automation yet
+
MILESTONE=1.8.1
 +
</nowiki></pre>
 +
 
 +
 
 +
==== Pre-flight checks ====
  
# Swift-core signoffs on RBP by accepting that change
+
'''Missing files check'''
 +
<pre><nowiki>
 +
./repo_tarball_diff.sh swift master
 
</nowiki></pre>
 
</nowiki></pre>
  
  
When that change hits trunk, trigger release process:
+
'''Check bugs'''
 +
* Look at the list of FixCommitted bugs, sanity-check that they were fixed during the period
  
<pre><nowiki>
 
PREVCOMMIT=abc0de..        # Last master commit before the one that just hit
 
  
# Make sure !FixCommitted bugs were actually fixed in that milestone (?)
+
==== RC1 tag ====
./process-fixcommitted-bugs.py swift --milestone $VER --check
 
  
# Create milestone-proposed branch from PREVCOMMIT
+
'''Get PTL signoff'''
#Not automated yet
+
* Get RC1 $RCSHA from PTL
#Go to https://review.openstack.org/ and sign in
+
* Check that the $MILESTONE changelog was committed to master
#Select Admin, Projects, then the project and Branches
 
#Enter milestone-proposed in the Branch Name field, and PREVCOMMIT as the Initial Revision
 
#Press Create Branch
 
  
# Target all !FixCommitted bugs to $VERSION milestone and !FixRelease them
 
./process-fixcommitted-bugs.py swift --milestone $VER --settarget $VER --fixrelease
 
  
# Wait for tarball generation at https://jenkins.openstack.org/job/swift-milestone-tarball/
+
'''Deferring blueprints'''
 +
* Move all incomplete blueprints to the next milestone ($MILESTONE should all be 'Implemented')
 +
* Move all incomplete bugs to the next milestone ($MILESTONE should all be 'Fix Committed')
  
# Wait for build at https://launchpad.net/~swift-core/+archive/milestone-proposed/+packages
 
  
# Call for testing
+
'''Tag RC1, wait for tarball build and process FixCommitted bugs'''
 +
<pre><nowiki>
 +
./swiftrc.sh $RC1SHA $MILESTONE
 
</nowiki></pre>
 
</nowiki></pre>
  
  
Select bugfixes should be pushed to milestone-proposed if need be. All those should be targeted to milestone and set to FixReleased when they hit. When milestone-proposed is ready for release:
+
'''Announce candidate builds'''
 +
* Email to openstack general ML
 +
* Twitter
 +
 
  
 +
==== Further RCs ====
 +
 +
We generally hope that intermediary Swift releases won't generate multiple RCs, but shit sometimes happens. In that case we follow a manual process.
  
<pre><nowiki>
 
# In milestone-proposed: in swift/__init__.py, change from False to True (leave $VERSION)
 
#Not automated yet
 
  
# Approve the merge on behalf of openstack-release
+
'''Set up proposed/$MILESTONE branch'''
#Not automated yet
+
* Go to review.openstack.org and create a proposed/$MILESTONE branch with the same SHA as the RC1 tag
 +
* Backport fixes to this branch
  
# Wait for tarball generation at https://jenkins.openstack.org/job/swift-milestone-tarball/
 
  
# Wait for build at https://launchpad.net/~swift-core/+archive/milestone-proposed/+packages
+
'''Manually push new tag on that branch'''
 +
<pre><nowiki>
 +
git checkout master && git pull
 +
git checkout -b proposed/$MILESTONE -t origin/proposed/$MILESTONE
 +
git tag -m "Swift $MILESTONE-rc2" -s "${MILESTONE}rc2" $RC2SHA
 +
git push gerrit ${MILESTONE}rc2
 
</nowiki></pre>
 
</nowiki></pre>
  
  
If everything went well, time to tag and release:
+
==== Release ====
 +
 
 +
'''Get PTL signoff'''
 +
* Get confirmation that SHA=RCxSHA
 +
 
  
 +
'''Tag, wait for tarball build, check similarities and upload'''
 
<pre><nowiki>
 
<pre><nowiki>
BUILD=20110922.r1293
+
./milestone.sh $MILESTONE $SHA swift
 +
</nowiki></pre>
 +
 
  
# In swift milestone-proposed: Tag release: $VER
+
'''Announce release'''
git checkout -t -b milestone-proposed origin/milestone-proposed
+
* Email to openstack general ML & openstack announce.
git pull
+
* Twitter
git tag $VER
+
* If a proposed/$MILESTONE branch was created, check that tags merged back to master and delete the branch (manually under review.openstack.org)
git push --tags gerrit
 
  
# Release $VER with resulting tarball
 
./upload_release.py swift $VER $BUILD
 
  
# Trigger rebuild of final version in PPA
+
== Final release ==
./reupload_with_new_version.py swift-core/milestone-proposed swift $VER
 
  
# Wait for build at https://launchpad.net/~swift-core/+archive/milestone-proposed/+packages
+
NB: The rccut.sh and rcdelivery.sh scripts special-case swift (where RC milestones are named differently) and oslo-incubator (where no tarball is published), so you can just run the same commands with them. They do '''not''' handle oslo.* libraries where tagging is external: bugs must be closed directly and stable branches created manually.
  
# Push to release PPA
+
<pre><nowiki>
./sync_ppas.py swift-core/milestone-proposed swift-core/release
+
PROJECT=nova
 +
SERIES=icehouse
 +
FINALSWIFT=2.0.0
 +
NEXTSERIES=juno
 +
</nowiki></pre>
  
# Wait for publication at https://launchpad.net/~swift-core/+archive/release/+packages
 
  
# Send email to mailing-list
+
==== Pre-flight checks ====
</nowiki></pre>
 
  
 +
'''Create next series'''
 +
* Create $NEXTSERIES series in Launchpad
 +
* Set status to Future, Set release manager
  
== Internal milestone release ==
 
  
For Nova, translations should be reasonably current:
+
'''Check RC1 has 'RC1' as short name'''
 +
* $NAME-rc1 should have 'RC1' as short milestone name
  
  
 +
'''Missing files check'''
 
<pre><nowiki>
 
<pre><nowiki>
(Translations merge is disabled for now)
+
./repo_tarball_diff.sh $PROJECT master
 
</nowiki></pre>
 
</nowiki></pre>
  
  
When trunk is ready for a milestone:
+
'''Check bugs'''
 +
* Look at the list of FixCommitted bugs, sanity-check that they were fixed during the period
 +
 
 +
 
 +
'''Check for translations /requirements updates'''
 +
* Branch should have a relatively recent translation update
 +
* Branch should have a relatively recent requirements update
  
  
<pre><nowiki>
+
==== stable/$SERIES branch cut (switch master to next version) ====
PROJECT=nova      # Project to release
 
VER=2012.1    # Current dev cycle
 
MILESTONE=essex-1  # Milestone to release (=VER for release)
 
MSTONE=e1          # Short name for $MILESTONE
 
NEWMSTONE=e2      # Short name for new milestone
 
  
# Make sure !FixCommitted bugs were actually fixed in that milestone (?)
+
'''Get PTL signoff'''
./process-fixcommitted-bugs.py $PROJECT --milestone $MILESTONE --check
+
* This should be done close to the RC1 cut
 +
* For Swift, check that the $FINALSWIFT changelog was committed to master
  
# Bump milestone in Jenkins
 
#Not automated yet
 
#Jenkins:common-bump-milestone set trunk to $NEWMSTONE (keep $MILESTONE for release)
 
</nowiki></pre>
 
  
 +
'''Push new version to master'''
 +
* Prepare change which sets next version on master branch in setup.cfg (except for Swift which doesn't set preversions)
 +
* Get it approved by core and make sure it's merged
 +
* Note down SHA = stable/$SERIES cut commit id (the commit just before the version bump)
  
'''Only for final release''':
 
  
 +
'''Create stable/$SERIES branch from previous commit, wait for tarball, process FixCommitted bugs'''
 
<pre><nowiki>
 
<pre><nowiki>
# Race condition: this must be the first commit of $NEWMSTONE !
+
./rccut.sh $SHA $SERIES $PROJECT [$FINALSWIFT]
# In master $PROJECT/version.py, propose change from $VER to $VER+1 (leave 'False')
 
#No automation yet
 
 
 
# $PROJECT-core signoffs on RBP  by accepting the branch
 
 
</nowiki></pre>
 
</nowiki></pre>
  
  
Then:
+
'''Set $NEXTSERIES as active development'''
 +
* Make $NEXTSERIES the "Development focus" for $PROJECT
 +
* Set $NEXTSERIES status to "Active development"
 +
* Set $SERIES status to "Pre-release freeze"
  
<pre><nowiki>
 
# In milestone-proposed, merge from $REV of trunk
 
#Not automated yet
 
#Go to https://review.openstack.org/ and sign in
 
#Select Admin, Projects, then the project and Branches
 
#Enter milestone-proposed in the Branch Name field, and HEAD as the Initial Revision
 
#Press Create Branch
 
  
# Target all !FixCommitted bugs to $MILESTONE milestone and !FixRelease them
+
==== RC1 cut ====
./process-fixcommitted-bugs.py $PROJECT --milestone $MILESTONE --settarget $MILESTONE --fixrelease
 
  
# Wait for tarball generation at https://jenkins.openstack.org/job/$PROJECT-milestone-tarball/
+
'''Get PTL signoff'''
 +
* Check that the branch contents are ready to go from PTL perspective (backport any last-minute bugfix)
  
# Wait for build at https://launchpad.net/~$PROJECT-core/+archive/milestone-proposed/+packages
 
  
# Call for testing
+
'''Tag, wait for tarball, check similarities and upload'''
 +
<pre><nowiki>
 +
./rcdelivery.sh $SERIES rc1 $PROJECT [$FINALSWIFT]
 
</nowiki></pre>
 
</nowiki></pre>
  
  
Select bugfixes should be pushed to milestone-proposed if need be. All those should be targeted to milestone. When milestone-proposed is ready for release:
+
'''Announce RC1'''
 +
* Email to openstack general ML
 +
* Twitter
 +
 
 +
 
 +
'''Unfreeze requirements'''
 +
* (should be doublechecked since we changed things here)
 +
* Create stable/$SERIES for openstack/requirements
 +
* Consider master branch unfrozen
 +
* Email to openstack dev ML
  
'''Milestone process:'''
 
  
<pre><nowiki>
+
==== Further RC-X windows ====
BUILD=20110727.r1143    # Look up latest milestone-proposed tarball name
 
  
# Bump milestone in Jenkins
+
'''Decision to open next RC window'''
#Not automated yet
+
* Consider $SERIES-rc-potential bugs and discuss with PTL if they warrant a respin
#Jenkins:common-bump-milestone set release to $NEWMSTONE (keep $NEWMSTONE for trunk)
 
  
# In milestone-proposed: Tag release: $MILESTONE
 
git checkout -t -b milestone-proposed origin/milestone-proposed
 
git pull
 
git tag $MILESTONE
 
git push --tags gerrit
 
  
# Release $MILESTONE with corresponding tarball (using --into for client tarballs)
+
'''Create RC-X milestone page'''
./upload_release.py [--into $LPPROJECT] $PROJECT $VER $BUILD $MILESTONE
+
* Create the RC-X milestone page (short name = RCX) on Launchpad
 +
* Target relevant bugs
  
# Rebuild final version in PPA
 
./reupload_with_new_version.py $PROJECT-core/milestone-proposed $PROJECT $VER~$MSTONE
 
  
# Wait for build at https://launchpad.net/~$PROJECT-core/+archive/milestone-proposed/+packages
+
'''Refine/fix bugs'''
 +
* Track bug fixes
 +
* Facilitate backports
  
# Push to milestone PPA
 
./sync_ppas.py $PROJECT-core/milestone-proposed $PROJECT-core/milestone
 
  
# Wait for publication at https://launchpad.net/~$PROJECT-core/+archive/milestone/+packages
+
'''Check for translations/requirements updates'''
 +
* Branch should have a relatively recent translation update. This requires a manual script to be run.
 +
* Requirements job (as proposed automatically when stable/* is created) should be merged if it exists
  
# Send email to mailing-list
 
</nowiki></pre>
 
  
 +
'''Get PTL signoff'''
 +
* Get confirmation that RC is releasable from PTL perspective
  
'''Final release process:'''
 
  
 +
'''Tag, wait for tarball, check similarities and upload'''
 
<pre><nowiki>
 
<pre><nowiki>
# In milestone-proposed: in $PROJECT/version.py, change from False to True (leave $VER)
+
./rcdelivery.sh $SERIES rcX $PROJECT [$FINALSWIFT]
#Not automated yet
+
</nowiki></pre>
 +
 
  
# Wait for tarball generation at https://jenkins.openstack.org/job/$PROJECT-milestone-tarball/
+
'''Announce RC-X'''
 +
* Email to openstack general ML
 +
* Twitter
  
# Wait for build at https://launchpad.net/~$PROJECT-core/+archive/milestone-proposed/+packages
 
  
# Note down last tarball build num
+
==== Final release ====
BUILD=20110727.r1143    # Look up latest milestone-proposed tarball name
 
  
# Bump milestone in Jenkins
+
'''Create final release milestone page'''
#Not automated yet
+
* Create the $VERSION final milestone page on Launchpad
#Jenkins:common-bump-milestone set release to $NEWMSTONE (keep $NEWMSTONE for trunk)
 
  
# In milestone-proposed: Tag release: $VER
 
git checkout -t -b milestone-proposed origin/milestone-proposed
 
git pull
 
git tag $VER
 
git push --tags gerrit
 
  
# Release $VERSION with corresponding tarball
+
'''Push all bugs and blueprints to final page'''
./upload_release.py $PROJECT $VER $BUILD
+
<pre><nowiki>
 +
./consolidate_release_page.py $PROJECT $SERIES $VERSION
 +
</nowiki></pre>
 +
This can take a very long time. For large bugs you will have to run it multiple times. Verify all intermediary milestone pages are now empty.
  
# Rebuild final version in PPA
 
./reupload_with_new_version.py $PROJECT-core/milestone-proposed $PROJECT $VER
 
  
# Wait for build at https://launchpad.net/~$PROJECT-core/+archive/milestone-proposed/+packages
+
'''Tag, wait for tarball, check similarities and upload'''
 +
<pre><nowiki>
 +
./rcdelivery.sh $SERIES final $PROJECT [$FINALSWIFT]
 +
</nowiki></pre>
  
# Push to milestone PPA
 
./sync_ppas.py $PROJECT-core/milestone-proposed $PROJECT-core/milestone
 
  
# Wait for publication at https://launchpad.net/~$PROJECT-core/+archive/milestone/+packages
+
'''Extra similarity check'''
 +
<pre><nowiki>
 +
./similar_tarballs.sh $PROJECT $VERSION.rcX $VERSION
 
</nowiki></pre>
 
</nowiki></pre>
  
  
== When all projects are done ==
+
'''Add release notes link to release page'''
 +
* Add the "See http://wiki.openstack.org/ReleaseNotes/$SERIES" note to the Release note on the download page.
  
<pre><nowiki>
 
# Create openstack-release PPA
 
#Not automated yet
 
  
# Push to openstack-release PPA
+
'''Announce release'''
./sync_ppas.py nova-core/milestone-proposed glance-core/milestone-proposed \
+
* openstack-announce, openstack general ML
              swift-core/milestone-proposed openstack-release/$VERSION
+
* Twitter etc.
 +
 
 +
 
 +
==== Post-release ====
 +
 
 +
'''Update wiki pages'''
 +
* http://wiki.openstack.org/Releases
 +
* https://wiki.openstack.org/wiki/Getting_The_Code
  
# Wait for publication at https://launchpad.net/~openstack-release/+archive/$VERSION/+packages
 
  
# Send email to mailing-list
+
'''Create openstack/openstack stable branch'''
</nowiki></pre>
+
* This needs to be done before any stable branch is created
 +
* Go to review.openstack.org openstack/openstack branch admin panel
 +
* New branch: "stable/$SERIES", Initial revision: "HEAD"
 +
* Push update to .gitmodules switching all "." to "stable/$SERIES"
  
  
= Random Howtos =
+
'''Switch dev focus'''
 +
* Switch $SERIES to current stable release, set release manager = openstack-stable-maint
 +
* Switch previous stable release (series - 1) to Obsolete
  
== Tag ==
 
* Go to Jenkins, nova-milestone job, click on Tags /!\ New job names to add
 
* Set the checkbox for the first in the list, set tag, click OK
 
  
== Release MILESTONE with TARBALL as MVERSION ==
+
'''Clean rc-potential tags'''
 +
* Search for https://bugs.launchpad.net/openstack/+bugs?field.tag=$SERIES-rc-potential
 +
* Remove tag where found
  
* Download http://PROJECT.openstack.org/tarballs/TARBALL.tar.gz
 
* Sanity-check tarball contents: tar tzf TARBALL.tar.gz
 
* Calculate MD5: md5sum TARBALL.tar.gz
 
* Rename file: mv TARBALL.tar.gz PROJECT-MVERSION.tar.gz
 
* Sign file: gpg --armor --sign --detach-sig PROJECT-MVERSION.tar.gz
 
* Mark milestone as released in Launchpad
 
** Go to https://launchpad.net/PROJECT/+milestone/MILESTONE
 
** Click on "Create release"
 
** Set release notes (if any)
 
* 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 ==
+
'''Enable stable/$SERIES'''
 +
* (should be doublechecked since we changed things here)
 +
* Add stable/$SERIES periodic jobs, example for Icehouse https://review.openstack.org/115933
  
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:
+
'''Push .1 version to stable/$SERIES branch'''
* Upload PKG-INFO from release tarball to set release details
+
<pre><nowiki>
* In "Files", Upload "source" tarball, any python version, with signature.
+
git checkout -t -b stable/$SERIES origin/stable/$SERIES
 +
git checkout -b stable-$SERIES
 +
vi setup.cfg # set to $VERSION.1
 +
vi .gitreview # set defaultbranch=stable/$SERIES
 +
git commit -a
 +
git review stable/$SERIES
 +
</nowiki></pre>
  
== Open new branch ==
+
NB: For Swift, it still makes sense to commit the the defaultbranch patch (even if you don't do the setup.cfg version bump)
* 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
 
** Go to https://launchpad.net/nova/
 
** "Development focus" on the front page. Change it.
 
** Go to the previous release, e.g. https://launchpad.net/nova/bexar
 
** Set it to obsolete
 
** Go to the one being released right now, e.g. https://launchpad.net/nova/cactus
 
** Set it to "Current stable release"
 

Latest revision as of 16:11, 13 June 2016

Caution icon.svg {{{header}}}

{{{body}}}

You can find all tools mentioned here in the openstack-infra/release-tools repository.

Development milestone publication

PROJECT=nova
MILESTONE=juno-3


Pre-flight checks

Missing files check (for all integrated projects doing the milestone)

./repo_tarball_diff.sh $PROJECT master


Milestone tag/publication (between Tuesday and Thursday)

All the integrated projects, as well as oslo-incubator and oslo.messaging, need to follow this process sometimes during the milestone publication window.

NB: The milestone.sh script special-cases oslo-incubator (where no tarball is published) and oslo.messaging (where no tag is pushed and no tarball is published) so you can just run the same commands with them.


Get PTL signoff (for all except oslo.messaging)

  • PTL confirms SHA for tag


Deferring blueprints and bugs

  • Move all incomplete blueprints to the next milestone ($MILESTONE should all be 'Implemented')
  • Move all incomplete bugs to the next milestone ($MILESTONE should all be 'Fix Committed'). You can use the following script:
./process_bugs.py $PROJECT --milestone $MILESTONE --settarget $NEXTMILESTONE


Tag, wait for tarball build, process FixCommitted bugs, check similarities and upload (if applicable)

./milestone.sh $MILESTONE $SHA $PROJECT


NB: for oslo.messaging $SHA is not used for tagging and is therefore ignored.


When all projects are done

Announce milestone

  • Email to openstack general ML
  • Twitter


Swift intermediary releases

PROJECT=swift
MILESTONE=1.8.1


Pre-flight checks

Missing files check

./repo_tarball_diff.sh swift master


Check bugs

  • Look at the list of FixCommitted bugs, sanity-check that they were fixed during the period


RC1 tag

Get PTL signoff

  • Get RC1 $RCSHA from PTL
  • Check that the $MILESTONE changelog was committed to master


Deferring blueprints

  • Move all incomplete blueprints to the next milestone ($MILESTONE should all be 'Implemented')
  • Move all incomplete bugs to the next milestone ($MILESTONE should all be 'Fix Committed')


Tag RC1, wait for tarball build and process FixCommitted bugs

./swiftrc.sh $RC1SHA $MILESTONE


Announce candidate builds

  • Email to openstack general ML
  • Twitter


Further RCs

We generally hope that intermediary Swift releases won't generate multiple RCs, but shit sometimes happens. In that case we follow a manual process.


Set up proposed/$MILESTONE branch

  • Go to review.openstack.org and create a proposed/$MILESTONE branch with the same SHA as the RC1 tag
  • Backport fixes to this branch


Manually push new tag on that branch

git checkout master && git pull
git checkout -b proposed/$MILESTONE -t origin/proposed/$MILESTONE
git tag -m "Swift $MILESTONE-rc2" -s "${MILESTONE}rc2" $RC2SHA
git push gerrit ${MILESTONE}rc2


Release

Get PTL signoff

  • Get confirmation that SHA=RCxSHA


Tag, wait for tarball build, check similarities and upload

./milestone.sh $MILESTONE $SHA swift


Announce release

  • Email to openstack general ML & openstack announce.
  • Twitter
  • If a proposed/$MILESTONE branch was created, check that tags merged back to master and delete the branch (manually under review.openstack.org)


Final release

NB: The rccut.sh and rcdelivery.sh scripts special-case swift (where RC milestones are named differently) and oslo-incubator (where no tarball is published), so you can just run the same commands with them. They do not handle oslo.* libraries where tagging is external: bugs must be closed directly and stable branches created manually.

PROJECT=nova
SERIES=icehouse
FINALSWIFT=2.0.0
NEXTSERIES=juno


Pre-flight checks

Create next series

  • Create $NEXTSERIES series in Launchpad
  • Set status to Future, Set release manager


Check RC1 has 'RC1' as short name

  • $NAME-rc1 should have 'RC1' as short milestone name


Missing files check

./repo_tarball_diff.sh $PROJECT master


Check bugs

  • Look at the list of FixCommitted bugs, sanity-check that they were fixed during the period


Check for translations /requirements updates

  • Branch should have a relatively recent translation update
  • Branch should have a relatively recent requirements update


stable/$SERIES branch cut (switch master to next version)

Get PTL signoff

  • This should be done close to the RC1 cut
  • For Swift, check that the $FINALSWIFT changelog was committed to master


Push new version to master

  • Prepare change which sets next version on master branch in setup.cfg (except for Swift which doesn't set preversions)
  • Get it approved by core and make sure it's merged
  • Note down SHA = stable/$SERIES cut commit id (the commit just before the version bump)


Create stable/$SERIES branch from previous commit, wait for tarball, process FixCommitted bugs

./rccut.sh $SHA $SERIES $PROJECT [$FINALSWIFT]


Set $NEXTSERIES as active development

  • Make $NEXTSERIES the "Development focus" for $PROJECT
  • Set $NEXTSERIES status to "Active development"
  • Set $SERIES status to "Pre-release freeze"


RC1 cut

Get PTL signoff

  • Check that the branch contents are ready to go from PTL perspective (backport any last-minute bugfix)


Tag, wait for tarball, check similarities and upload

./rcdelivery.sh $SERIES rc1 $PROJECT [$FINALSWIFT]


Announce RC1

  • Email to openstack general ML
  • Twitter


Unfreeze requirements

  • (should be doublechecked since we changed things here)
  • Create stable/$SERIES for openstack/requirements
  • Consider master branch unfrozen
  • Email to openstack dev ML


Further RC-X windows

Decision to open next RC window

  • Consider $SERIES-rc-potential bugs and discuss with PTL if they warrant a respin


Create RC-X milestone page

  • Create the RC-X milestone page (short name = RCX) on Launchpad
  • Target relevant bugs


Refine/fix bugs

  • Track bug fixes
  • Facilitate backports


Check for translations/requirements updates

  • Branch should have a relatively recent translation update. This requires a manual script to be run.
  • Requirements job (as proposed automatically when stable/* is created) should be merged if it exists


Get PTL signoff

  • Get confirmation that RC is releasable from PTL perspective


Tag, wait for tarball, check similarities and upload

./rcdelivery.sh $SERIES rcX $PROJECT [$FINALSWIFT]


Announce RC-X

  • Email to openstack general ML
  • Twitter


Final release

Create final release milestone page

  • Create the $VERSION final milestone page on Launchpad


Push all bugs and blueprints to final page

./consolidate_release_page.py $PROJECT $SERIES $VERSION

This can take a very long time. For large bugs you will have to run it multiple times. Verify all intermediary milestone pages are now empty.


Tag, wait for tarball, check similarities and upload

./rcdelivery.sh $SERIES final $PROJECT [$FINALSWIFT]


Extra similarity check

./similar_tarballs.sh $PROJECT $VERSION.rcX $VERSION


Add release notes link to release page


Announce release

  • openstack-announce, openstack general ML
  • Twitter etc.


Post-release

Update wiki pages


Create openstack/openstack stable branch

  • This needs to be done before any stable branch is created
  • Go to review.openstack.org openstack/openstack branch admin panel
  • New branch: "stable/$SERIES", Initial revision: "HEAD"
  • Push update to .gitmodules switching all "." to "stable/$SERIES"


Switch dev focus

  • Switch $SERIES to current stable release, set release manager = openstack-stable-maint
  • Switch previous stable release (series - 1) to Obsolete


Clean rc-potential tags


Enable stable/$SERIES


Push .1 version to stable/$SERIES branch

git checkout -t -b stable/$SERIES origin/stable/$SERIES
git checkout -b stable-$SERIES
vi setup.cfg # set to $VERSION.1
vi .gitreview # set defaultbranch=stable/$SERIES
git commit -a
git review stable/$SERIES

NB: For Swift, it still makes sense to commit the the defaultbranch patch (even if you don't do the setup.cfg version bump)