Jump to: navigation, search

Difference between revisions of "StableBranchRelease"

(Clean up the release instructions)
Line 12: Line 12:
 
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: 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 tarballs job in Jenkins is building tarballs correctly for each project e.g. check [http://tarballs.openstack.org/nova/?C=M;O=D here for nova] that a tarball is being built from the stable branch each time a commit is pushed there.
 +
# Discuss your plans for the release at the weekly project meeting.
 +
# Create a launchpad milestone for each project for the version you're planning to release.
 +
# Add all bugs fixed on the stable branch to the appropriate launchpad and target to the milestone you've just created.  
 
<pre><nowiki>
 
<pre><nowiki>
GLANCE_VERSION = ['2012', '1', '2']
+
# Gather a list of bugs fixed since the previous release
</nowiki></pre>
+
$> git log  2012.1.2..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
 
 
Also, make FINAL = False for now. Keystone doesn't have this field, though.
 
# 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
 
# Sanity check that list of bugs
 
$> python showbugs.py $(cat nova-bugs.txt)
 
$> python showbugs.py $(cat nova-bugs.txt)
# Nominate those bugs for essex
+
# Nominate those bugs for the series
 
$> python nominate.py nova essex $(cat nova-bugs.txt)
 
$> python nominate.py nova essex $(cat nova-bugs.txt)
# Target those bugs for 2012.1.2
+
# Target those bugs at the milestone
$> python target.py nova essex 2012.1.2 $(cat nova-bugs.txt)
+
$> python target.py nova essex 2012.1.3 $(cat nova-bugs.txt)
 
</nowiki></pre>
 
</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:
 
<pre><nowiki>
 
GLANCE_VERSION = ['2012', '1', '3']
 
FINAL = False</nowiki></pre>
 
  
 +
# Call for testing, see [https://lists.launchpad.net/openstack/msg17332.html this example]
 +
# When the stable team feel feel the release is ready, the release team obtains PTL approval and informs the TC.
 +
# Push a commit to branch which does:<code><nowiki>FINAL = True</nowiki></code>
 
# Tag the release:
 
# Tag the release:
 
<pre><nowiki>
 
<pre><nowiki>
$> git tag -s 2012.1.2
+
$> git tag -s 2012.1.3
$> git push gerrit tag 2012.1.2</nowiki></pre>
+
$> git push gerrit tag 2012.1.3</nowiki></pre>
  
# Mark all Essex [[FixCommitted]] bugs as [[FixReleased]]. With a small change:
+
# Mark all [[FixCommitted]] bugs as [[FixReleased]]. With a small change:
 
<pre><nowiki>
 
<pre><nowiki>
 
+series = proj.getSeries(name='essex')
 
+series = proj.getSeries(name='essex')
Line 53: Line 42:
 
  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 nova --onlymilestone 2012.1.3 --fixrelease
 
</nowiki></pre>
 
</nowiki></pre>
  
 
# Upload the release:
 
# Upload the release:
 
<pre><nowiki>
 
<pre><nowiki>
$> ./upload_release.py glance 2012.1.2 20120810.1435</nowiki></pre>
+
$> ./upload_release.py nova 2012.1.3 20121012.13710</nowiki></pre>
  
# PPA updates. (Delegate to openstack-ppa team?)
+
# Update [[SecurityAdvisories/Folsom]]
# Send release announcement.
+
# Write release notes like [[ReleaseNotes/2012.1.3]]
 +
# Send release announcement like [https://lists.launchpad.net/openstack/msg17403.html this example].
 +
# Open development for the next release by increasing the micro version in e.g. <code><nowiki>NOVA_VERSION</nowiki></code> and setting <code><nowiki>FINAL = False</nowiki></code>

Revision as of 21:19, 13 October 2012

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.

  1. 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.
  2. 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.
  3. Discuss your plans for the release at the weekly project meeting.
  4. Create a launchpad milestone for each project for the version you're planning to release.
  5. Add all bugs fixed on the stable branch to the appropriate launchpad and target to the milestone you've just created.
# Gather a list of bugs fixed since the previous release
$> git log  2012.1.2..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 the series
$> python nominate.py nova essex $(cat nova-bugs.txt)
# Target those bugs at the milestone
$> python target.py nova essex 2012.1.3 $(cat nova-bugs.txt)
  1. Call for testing, see this example
  2. When the stable team feel feel the release is ready, the release team obtains PTL approval and informs the TC.
  3. Push a commit to branch which does:FINAL = True
  4. Tag the release:
$> git tag -s 2012.1.3
$> git push gerrit tag 2012.1.3
  1. Mark all FixCommitted bugs as FixReleased. With a small change:
+series = proj.getSeries(name='essex')
+bugtasks = series.searchTasks(status='Fix Committed', omit_targeted=False)
we can use process-fixcommitted-bugs.py:
$> python ./process-fixcommitted-bugs.py nova --onlymilestone 2012.1.3 --fixrelease
  1. Upload the release:
$> ./upload_release.py nova 2012.1.3 20121012.13710
  1. Update SecurityAdvisories/Folsom
  2. Write release notes like ReleaseNotes/2012.1.3
  3. Send release announcement like this example.
  4. Open development for the next release by increasing the micro version in e.g. NOVA_VERSION and setting FINAL = False