Jump to: navigation, search

Difference between revisions of "StableBranchRelease"

 
(102 intermediate revisions by 9 users not shown)
Line 1: Line 1:
__NOTOC__
+
{{caution|http://docs.openstack.org/project-team-guide/stable-branches.html|The stable branch policy is now maintained in the project team guide:}}
= Stable Branch Releases =
+
'''This information is about coordinated releases from the stable branch up to OpenStack Kilo. For stable/liberty and later see [openstack-dev] [release] stable branch release process changes [http://lists.openstack.org/pipermail/openstack-dev/2015-November/078281.html]
 +
'''
  
The [https://launchpad.net/~openstack-stable-maint openstack-stable-maint] team rigorously applies the documented [[StableBranch]] principles and works hard to include appropriate bugfixes from master on the stable branch while limiting the risk of regressions. The intention is for releases published from the stable branch to be a safe source of fixes for high-impact user-visible issues.
+
You can see a history of these releases on the [[Releases]] page.
  
The [[ReleaseTeam]] is responsible for all [[OpenStack]] release deliveries and [[markmc]] coordinates releases from the stable branch. Stable branch releases are expected roughly every 8 weeks, depending on how many fixes are queued up.
+
= Stable Branch Releases =
  
You can see a history of these releases on the [[Releases]] page.
+
__TOC__
  
 
== How To Release ==
 
== How To Release ==
Line 12: Line 13:
 
Below is the checklist of steps required to carry out this release, heavily based on [[ReleaseTeam/HowToRelease]].
 
Below is the checklist of steps required to carry out this release, heavily based on [[ReleaseTeam/HowToRelease]].
  
# Versioning: push a change to <code><nowiki>stable/essex</nowiki></code> to to <code><nowiki>{NOVA,GLANCE}_VERSION</nowiki></code> e.g.  
+
=== Versioning ===
<pre><nowiki>
+
 
GLANCE_VERSION = ['2012', '1', '2']
+
Make sure the current versioning on the stable branch of each project is correct - e.g. the version in <code><nowiki>setup.cfg</nowiki></code> is the same as the version you intend to release.
</nowiki></pre>
+
 
 +
=== Tarballs ===
 +
 
 +
Make sure the tarballs job in Jenkins is building tarballs correctly for each project e.g. check [http://tarballs.openstack.org/nova/nova-stable-icehouse.tar.gz here for Nova Icehouse] that a tarball is being built from the stable branch each time a commit is pushed there.
 +
 
 +
=== Warn People ===
 +
 
 +
Discuss your plans for the release at the weekly project meeting.
 +
 
 +
Preferably set a date for the release immediately after the previous release.
 +
 
 +
=== Milestones ===
 +
 
 +
Create a launchpad milestone for each project for the version you're planning to release.
 +
 
 +
=== Bugs ===
 +
 
 +
Note: [https://bugs.launchpad.net/launchpad/+bug/1081197 only project drivers can target bugs to a series] so the release manager needs to find bugs tagged with '''in-stable-icehouse''' and target them.
 +
 
 +
# Gather a list of bugs fixed since the previous release e.g.  <pre><nowiki>$> git log --no-merges --topo-order 2014.1.1.. | grep -i '\(bug\|lp\)[: #]*' | sed 's/.*\(1[0-9][0-9][0-9][0-9][0-9][0-9]\).*/\1/' > nova-bugs.txt</nowiki></pre>
 +
# Using scripts from http://github.com/markmc/openstack-lp-scripts sanity check the list of bugs. Check that each has had a patch proposed to the stable branch <pre><nowiki>$> python showbugs.py $(cat nova-bugs.txt)</nowiki></pre>
 +
# Nominate those bugs for the series <pre><nowiki>$> python nominate.py nova icehouse $(cat nova-bugs.txt)</nowiki></pre>
 +
# Target those bugs at the milestone <pre><nowiki>$> python target.py nova icehouse 2014.1.2 $(cat nova-bugs.txt)</nowiki></pre>
 +
# Review the list of bugs targeted to the milestone and fixup Importance and Assignee fields e.g. https://bugs.launchpad.net/nova/+milestone/2014.1.1
 +
# Review bugs tagged with '''in-stable-icehouse''' and target them appropriately if they haven't already been targeted. Don't forget to remove the tag. e.g. [https://bugs.launchpad.net/nova/+bugs?field.tag=in-stable-icehouse&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE a query for nova]
 +
# Review bugs tagged with '''icehouse-backport-potential''', untag fixes already backported and consider backporting important ones. e.g. [https://bugs.launchpad.net/nova/+bugs?field.tag=icehouse-backport-potential&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE a query for nova].
 +
# Check to see if [https://bugs.launchpad.net/nova/icehouse/+nominations any bugs were nominated for the series]
 +
# Look at open reviews and make sure the corresponding bugs are targeted. e.g. [https://review.openstack.org/#/q/branch:stable/icehouse+status:open+project:openstack/nova,n,z query for nova].
 +
 
 +
=== Call For Testing ===
  
Also, make FINAL = False for now. Keystone doesn't have this field, though.
+
Call for testing, see [http://lists.openstack.org/pipermail/openstack-dev/2013-August/013059.html this example]
# Make sure the tarballs job in Jenkins is building stable/essex tarballs e.g. [http://glance.openstack.org/tarballs/glance-2012.1.1~20120615.1435.tar.gz glance-2012.1.1~20120615.1435.tar.gz].
 
# Add all bugs fixed on stable/essex to the Essex series in launchpad and assign to the created <code><nowiki>2012.1.2</nowiki></code> target.
 
<pre><nowiki>
 
# Gather a list of bugs fixed on stable/essex since 2012.2
 
$> git log  2011.1..origin/stable/essex | grep '[0-9][0-9][0-9][0-9][0-9][0-9]' | grep -v '^\(commit \|Merge\)' | grep -v -i '\(cherry[ -]picked\|Change-Id\|bugzilla\)' | sed 's/.*\([0-9][0-9][0-9][0-9][0-9][0-9]\).*/\1/g' | sort | uniq > nova-bugs.txt
 
# Sanity check that list of bugs
 
$> python showbugs.py $(cat nova-bugs.txt)
 
# Nominate those bugs for essex
 
$> python nominate.py nova essex $(cat nova-bugs.txt)
 
# Target those bugs for 2012.1.2
 
$> python target.py nova essex 2012.1.2 $(cat nova-bugs.txt)
 
</nowiki></pre>
 
The stable team is the release manager for the essex series (with the release team added to the stable team, to assist) and the release manager accepts bugs nominated for the essex series. Bugs are marked as [[FixCommitted]] in essex when they are accepted onto stable/essex.
 
# Call for testing
 
# When the stable team feel feel the release is ready, the release team obtains PTL approval and informs the PPB.
 
# Push a commit to stable/diablo which does:
 
<pre><nowiki>
 
FINAL = True</nowiki></pre>
 
  
and once the tarball has been generated, push:
+
=== Tag ===
<pre><nowiki>
+
# Tag the release: <pre><nowiki>$> git fetch gerrit; git tag -m 2014.1.2 -s 2014.1.2 gerrit/stable/icehouse</nowiki></pre>
GLANCE_VERSION = ['2012', '1', '3']
+
# Bump version in setup.cfg BEFORE pushing the tags e.g. https://review.openstack.org/#/q/I3a7170180717bd62fce4cbc2c3a9107187f89fb1,n,z
FINAL = False</nowiki></pre>
+
# Push the tags for each project<pre><nowiki>$> git push gerrit tag 2014.1.2</nowiki></pre>
  
# Tag the release:
+
=== Close bugs ===
<pre><nowiki>
 
$> git tag -s 2012.1.2
 
$> git push gerrit tag 2012.1.2</nowiki></pre>
 
  
# Mark all Essex [[FixCommitted]] bugs as [[FixReleased]]. With a small change:
+
# Using http://github.com/markmc/openstack-lp-scripts mark all [[FixCommitted]] bugs as [[FixReleased]]. With a small change:
 
<pre><nowiki>
 
<pre><nowiki>
+series = proj.getSeries(name='essex')
+
+series = proj.getSeries(name='icehouse')
 
+bugtasks = series.searchTasks(status='Fix Committed', omit_targeted=False)</nowiki></pre>
 
+bugtasks = series.searchTasks(status='Fix Committed', omit_targeted=False)</nowiki></pre>
we can use <code><nowiki>process-fixcommitted-bugs.py</nowiki></code>:
+
we can use <code><nowiki>process-fixcommitted-bugs.py</nowiki></code>:
 
<pre><nowiki>
 
<pre><nowiki>
$> python ./process-fixcommitted-bugs.py keystone --onlymilestone 2012.1.2 --fixrelease
+
$> python ./process-fixcommitted-bugs.py --onlymilestone 2014.1.2 --fixrelease nova
 
</nowiki></pre>
 
</nowiki></pre>
 +
NB: script might fail updating bugs with lots of tasks e.g. bug 1251757 - skip them using optional "exceptions" parameters e.g.
 +
<pre><nowiki>
 +
$> python ./process-fixcommitted-bugs.py --onlymilestone 2013.2.1 --fixrelease nova 1257293 1251757
 +
</nowiki></pre>
 +
 +
=== Upload The Release ===
 +
 +
Using http://github.com/openstack-infra/release-tools
  
 
# Upload the release:
 
# Upload the release:
 
<pre><nowiki>
 
<pre><nowiki>
$> ./upload_release.py glance 2012.1.2 20120810.1435</nowiki></pre>
+
$> python ./upload_release.py nova 2014.1.2
 +
</nowiki></pre>
 +
 
 +
=== Once all done ===
 +
 
 +
# Write release notes like [[ReleaseNotes/2014.1.1]]
 +
# Send release announcement like [[StableBranchRelease/BoilerPlateAnnounce]].
 +
# Propose an openstack/releases change, like https://review.openstack.org/210547
 +
 
 +
=== Rinse, Repeat ===
 +
 
 +
# Decide on date for next release, create milestones
 +
 
 +
==== Planned stable/juno releases (12 months) ====
 +
 
 +
<strike>
 +
2014.2.1  Dec 4 2014, release manager: apevec
 +
2014.2.2  Feb 5 2015, release manager: zulcss
 +
2014.2.3  Apr 9 2015, release manager: adam_g
 +
2014.2.4 (eol) mid November, 2015. release manager: apevec</strike>
 +
 
 +
==== Planned stable/kilo releases (12 months) ====
  
# PPA updates. (Delegate to openstack-ppa team?)
+
* <strike> 2015.1.1  July 16, 2015, release manager: apevec</strike>
# Send release announcement.
+
* <strike> 2015.1.2  mid-October, 2015, release manager: zulcss</strike>
 +
* <strike> 2015.1.3 ~January, 2016, release manager: Daviey</strike>
 +
* 2015.1.4 (eol) ~2016-05-02, release manager Daviey

Latest revision as of 07:51, 11 March 2016

Caution icon.svg {{{header}}}

{{{body}}}

This information is about coordinated releases from the stable branch up to OpenStack Kilo. For stable/liberty and later see [openstack-dev] [release] stable branch release process changes [1]

You can see a history of these releases on the Releases page.

Stable Branch Releases

How To Release

Below is the checklist of steps required to carry out this release, heavily based on ReleaseTeam/HowToRelease.

Versioning

Make sure the current versioning on the stable branch of each project is correct - e.g. the version in setup.cfg is the same as the version you intend to release.

Tarballs

Make sure the tarballs job in Jenkins is building tarballs correctly for each project e.g. check here for Nova Icehouse that a tarball is being built from the stable branch each time a commit is pushed there.

Warn People

Discuss your plans for the release at the weekly project meeting.

Preferably set a date for the release immediately after the previous release.

Milestones

Create a launchpad milestone for each project for the version you're planning to release.

Bugs

Note: only project drivers can target bugs to a series so the release manager needs to find bugs tagged with in-stable-icehouse and target them.

  1. Gather a list of bugs fixed since the previous release e.g.
    $> git log --no-merges --topo-order 2014.1.1.. | grep -i '\(bug\|lp\)[: #]*' | sed 's/.*\(1[0-9][0-9][0-9][0-9][0-9][0-9]\).*/\1/' > nova-bugs.txt
  2. Using scripts from http://github.com/markmc/openstack-lp-scripts sanity check the list of bugs. Check that each has had a patch proposed to the stable branch
    $> python showbugs.py $(cat nova-bugs.txt)
  3. Nominate those bugs for the series
    $> python nominate.py nova icehouse $(cat nova-bugs.txt)
  4. Target those bugs at the milestone
    $> python target.py nova icehouse 2014.1.2 $(cat nova-bugs.txt)
  5. Review the list of bugs targeted to the milestone and fixup Importance and Assignee fields e.g. https://bugs.launchpad.net/nova/+milestone/2014.1.1
  6. Review bugs tagged with in-stable-icehouse and target them appropriately if they haven't already been targeted. Don't forget to remove the tag. e.g. a query for nova
  7. Review bugs tagged with icehouse-backport-potential, untag fixes already backported and consider backporting important ones. e.g. a query for nova.
  8. Check to see if any bugs were nominated for the series
  9. Look at open reviews and make sure the corresponding bugs are targeted. e.g. query for nova.

Call For Testing

Call for testing, see this example

Tag

  1. Tag the release:
    $> git fetch gerrit; git tag -m 2014.1.2 -s 2014.1.2 gerrit/stable/icehouse
  2. Bump version in setup.cfg BEFORE pushing the tags e.g. https://review.openstack.org/#/q/I3a7170180717bd62fce4cbc2c3a9107187f89fb1,n,z
  3. Push the tags for each project
    $> git push gerrit tag 2014.1.2

Close bugs

  1. Using http://github.com/markmc/openstack-lp-scripts mark all FixCommitted bugs as FixReleased. With a small change:
+series = proj.getSeries(name='icehouse')
+bugtasks = series.searchTasks(status='Fix Committed', omit_targeted=False)

we can use process-fixcommitted-bugs.py:

$> python ./process-fixcommitted-bugs.py --onlymilestone 2014.1.2 --fixrelease nova

NB: script might fail updating bugs with lots of tasks e.g. bug 1251757 - skip them using optional "exceptions" parameters e.g.

$> python ./process-fixcommitted-bugs.py --onlymilestone 2013.2.1 --fixrelease nova 1257293 1251757

Upload The Release

Using http://github.com/openstack-infra/release-tools

  1. Upload the release:
$> python ./upload_release.py nova 2014.1.2

Once all done

  1. Write release notes like ReleaseNotes/2014.1.1
  2. Send release announcement like StableBranchRelease/BoilerPlateAnnounce.
  3. Propose an openstack/releases change, like https://review.openstack.org/210547

Rinse, Repeat

  1. Decide on date for next release, create milestones

Planned stable/juno releases (12 months)

2014.2.1  Dec 4 2014, release manager: apevec
2014.2.2  Feb 5 2015, release manager: zulcss
2014.2.3  Apr 9 2015, release manager: adam_g
2014.2.4 (eol) mid November, 2015. release manager: apevec

Planned stable/kilo releases (12 months)

  • 2015.1.1 July 16, 2015, release manager: apevec
  • 2015.1.2 mid-October, 2015, release manager: zulcss
  • 2015.1.3 ~January, 2016, release manager: Daviey
  • 2015.1.4 (eol) ~2016-05-02, release manager Daviey