Jump to: navigation, search

Difference between revisions of "StableBranchRelease"

m (Text replace - "__NOTOC__" to "")
Line 14: Line 14:
 
=== Versioning ===
 
=== Versioning ===
  
Make sure the current versioning on the stable branch of each project is correct - e.g. the version in <code><nowiki>NOVA_VERSION</nowiki></code> is the same as the version you intend to release and <code><nowiki>FINAL = False</nowiki></code>. Note, keystone is a little different and stores its version in <code><nowiki>setup.py</nowiki></code>.
+
Make sure the current versioning on the stable branch of each project is correct - e.g. the version in <code><nowiki>NOVA_VERSION</nowiki></code> is the same as the version you intend to release and <code><nowiki>FINAL = False</nowiki></code>. Note, Keystone is a little different and stores its version in <code><nowiki>setup.py</nowiki></code>.
  
 
=== Tarballs ===
 
=== Tarballs ===
Line 66: Line 66:
 
=== Tag ===
 
=== Tag ===
  
# Push a commit to branch which does:<code><nowiki>FINAL = True</nowiki></code>
+
# Push a commit to branch which does:<code><nowiki>FINAL = True</nowiki></code> to nova, cinder, quantum and horizon e.g. https://review.openstack.org/#/q/Ic83a1c1617ad74b931f54f1755bc9dcecfe2c527,n,z Keystone and Glance do not have FINAL variable.
 
# Tag the release:
 
# Tag the release:
 
<pre><nowiki>
 
<pre><nowiki>

Revision as of 01:18, 11 April 2013

Stable Branch Releases

The 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.

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.

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

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 NOVA_VERSION is the same as the version you intend to release and FINAL = False. Note, Keystone is a little different and stores its version in setup.py.

Tarballs

Make sure the tarballs job in Jenkins is building tarballs correctly for each project e.g. check here for nova 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-folsom and target them.

  1. Gather a list of bugs fixed since the previous release e.g.
$> git log --no-merges --topo-order 2012.2.1.. | grep -i '\(bug\|lp\)[: #]*' | sed 's/.*\(1[0-9][0-9][0-9][0-9][0-9][0-9]\).*/\1/' > nova-bugs.txt
  1. 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)
  1. Nominate those bugs for the series
$> python nominate.py nova essex $(cat nova-bugs.txt)
  1. Target those bugs at the milestone
$> python target.py nova folsom 2012.2.3 $(cat nova-bugs.txt)
  1. Review the list of bugs targeted to the milestone and fixup Importance and Assignee fields e.g. https://bugs.launchpad.net/nova/+milestone/2012.2.3
  2. Review bugs tagged with in-stable-folsom and target them appropriately if they haven't already been targeted. Don't forget to remove the tag. e.g. a query for nova
  3. Review bugs tagged with folsom-backport-potential, untag fixes already backported and consider backporting important ones. e.g. a query for nova.
  4. Check to see if any bugs were nominated for the series
  5. 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. Push a commit to branch which does:FINAL = True to nova, cinder, quantum and horizon e.g. https://review.openstack.org/#/q/Ic83a1c1617ad74b931f54f1755bc9dcecfe2c527,n,z Keystone and Glance do not have FINAL variable.
  2. Tag the release:
$> git tag -s 2012.2.3
$> git push gerrit tag 2012.2.3


Close bugs

  1. Mark all FixCommitted bugs as FixReleased. With a small change:
+series = proj.getSeries(name='folsom')
+bugtasks = series.searchTasks(status='Fix Committed', omit_targeted=False)
we can use process-fixcommitted-bugs.py:
$> python ./process-fixcommitted-bugs.py nova --onlymilestone 2012.2.3 --fixrelease


Upload The Release

Using https://github.com/ttx/openstack-releasing

  1. Upload the release:
$> python ./upload_release.py nova 2012.2.3 --tarball=stable-folsom


Docs

  1. Update SecurityAdvisories/Folsom
  2. Write release notes like ReleaseNotes/2012.1.3
  3. Send release announcement like this example.
  4. Update Releases

Rinse, Repeat

  1. Open development for the next release by increasing the micro version in e.g. NOVA_VERSION and setting FINAL = False
  2. Decide on date for next release, create milestones