← Back to team overview

yellow team mailing list archive

[Merge] lp:~frankban/juju-gui/release-process-fixes into lp:juju-gui

 

Francesco Banconi has proposed merging lp:~frankban/juju-gui/release-process-fixes into lp:juju-gui.

Requested reviews:
  Juju GUI Hackers (juju-gui)
Related bugs:
  Bug #1095605 in juju-gui: "Fix release process documentation"
  https://bugs.launchpad.net/juju-gui/+bug/1095605

For more details, see:
https://code.launchpad.net/~frankban/juju-gui/release-process-fixes/+merge/141738

Fix release process documentation

And other minor changes, like text formatting fixes 
and trailing spaces removal.

https://codereview.appspot.com/7039049/

-- 
https://code.launchpad.net/~frankban/juju-gui/release-process-fixes/+merge/141738
Your team Juju GUI Hackers is requested to review the proposed merge of lp:~frankban/juju-gui/release-process-fixes into lp:juju-gui.
=== modified file 'docs/process.rst'
--- docs/process.rst	2012-12-21 02:16:06 +0000
+++ docs/process.rst	2013-01-03 11:51:31 +0000
@@ -106,8 +106,8 @@
 =====================================
 
 - Get a clean branch of the trunk:: ``bzr branch lp:juju-gui``.
-- If you are using a pre-existing branch, make sure it is up-to-date:: ``bzr
-  pull``.
+- If you are using a pre-existing branch, make sure it is up-to-date::
+  ``bzr pull``.
 - Verify that the top-most version in CHANGES.yaml specifies the expected
   version string.  It should be bigger than the most recent version found on
   https://launchpad.net/juju-gui/stable .  If the most recent version string
@@ -115,24 +115,25 @@
 
   * Decide what the next version number should be (see http://semver.org/) and
     change "unreleased" to that value.
-  * Commit to the branch with this checkin message: ``bzr commit -m 'Set
-    version for release.'``
-  * Push the branch directly to the parent (``bzr push`` should work).
+  * Commit to the branch with this checkin message:
+    ``bzr commit -m 'Set version for release.'``
+  * Push the branch directly to the parent (``bzr push :parent`` should work).
 
-- Run the tests and verify they pass: ``make test-prod`` and then
-  ``make test-debug``.
+- Run the tests and verify they pass: ``FINAL=1 make test-prod`` and then
+  ``FINAL=1 make test-debug``.
 - Create the tarball: ``FINAL=1 make distfile``.  The process will end by
   reporting the name of the tarball it made.
 - In an empty temporary directory somewhere else on your system, expand the
   tarball: ``tar xvzf PATH_TO_TARBALL``
-- In that directory, start a server: ``python -m SimpleHTTPServer 8888``
+- In the ``build-prod`` directory, inside the uncompressed one, start a server:
+  ``python -m SimpleHTTPServer 8888``
 - In Chrome and Firefox, QA the application.  At the very least, load the app,
   open the charm panel, go to an inner page, and make sure there are no 404s
   or Javascript errors in the console.  We want a real QA script for the
   future.
 - For now, we will assume you would like to verify the release on the
   Launchpad staging server.  As we become more confident with this process,
-  this step may become unnecessary.  In the checkout, run ``FINAL=1 make
+  this step may become unnecessary.  In the branch, run ``FINAL=1 make
   dist``.  This will step you through signing the tarball, connecting
   to Launchpad, and uploading the release.
 
@@ -151,8 +152,9 @@
   SimpleHTTPServer 8888``, and do a quick double-check in the browser that it
   is what you expect.  Looking at juju-ui/version.js should also show you the
   version you expect.
-- This is a final release.  Consider asking others to verify the package on staging.
-- Now it is time for the actual, real release.  Head back to your checkout and
+- This is a final release.  Consider asking others to verify the package on
+  staging.
+- Now it is time for the actual, real release.  Head back to your branch and
   run ``FINAL=1 PROD=1 make dist``.  The computer will again walk you
   through the process.
 
@@ -165,6 +167,13 @@
 - Go to https://launchpad.net/juju-gui/stable and verify that you see
   a new release and a new download file.
 
+- Set the version back to ``unreleased`` by doing the following.
+
+  * Restore ``- unreleased:`` as most recent version string in CHANGES.yaml.
+  * Commit to the branch with this checkin message:
+    ``bzr commit -m 'Set version back to unreleased.'``
+  * Push the branch directly to the parent (``bzr push :parent`` should work).
+
 You are done!
 
 Checklist for Making a Developer Release
@@ -174,23 +183,25 @@
 - If you are using a pre-existing branch, make sure it is up-to-date::
   ``bzr pull``.
 - Verify that the top-most version in CHANGES.yaml is "unreleased."
-- Run ``bzr revno``.  The revno should be bigger than the most recent release found on
-  `Launchpad <https://launchpad.net/juju-gui/trunk>`_.
-- Run the tests and verify they pass: ``make test``.
+- Run ``bzr revno``.  The revno should be bigger than the most recent release
+  found on `Launchpad <https://launchpad.net/juju-gui/trunk>`_.
+- Run the tests and verify they pass: ``make test-prod`` and then
+  ``make test-debug``.
 - Create the tarball: ``make distfile``.  It will end by reporting the name of
   the tarball it made.
 - In an empty temporary directory somewhere else on your system, expand the
   tarball: ``tar xvzf PATH_TO_TARBALL``.
-- Looking at juju-ui/version.js should show you a version string that combines
-  the value in the checkout's CHANGES.yaml with the checkout's revno.
-- In that directory, start a server: ``python -m SimpleHTTPServer 8888``
+- Looking at ``build-prod/juju-ui/version.js`` should show you a version string
+  that combines the value in the branch's CHANGES.yaml with the branch's revno.
+- In the ``build-prod`` directory, start a server:
+  ``python -m SimpleHTTPServer 8888``
 - In Chrome and Firefox, QA the application.  At the very least, load the app,
   open the charm panel, go to an inner page, and make sure there are no 404s
   or Javascript errors in the console.  We want a real QA script for the
   future.
 - For now, we will assume you would like to verify the release on the
   Launchpad staging server.  As we become more confident with this process,
-  this step may become unnecessary.  In the checkout, run ``make dist``.
+  this step may become unnecessary.  In the branch, run ``make dist``.
   This will step you through signing the tarball, connecting to
   Launchpad, and uploading the release.
 
@@ -209,7 +220,7 @@
   SimpleHTTPServer 8888``, and do a quick double-check in the browser that it
   is what you expect.  Looking at juju-ui/version.js should also show you the
   version you expect, as seen in the similar earlier step above.
-- Now it is time for the actual, real release.  Head back to your checkout and
+- Now it is time for the actual, real release.  Head back to your branch and
   run ``PROD=1 make dist``.  The computer will again walk you through the
   process.
 
@@ -228,14 +239,14 @@
 ======================================
 
 Within a checkout, a lightweight checkout, or a branch, you may run make as
-``NO_BZR=1 make [target]`` in order to prevent the Makefile from running 
+``NO_BZR=1 make [target]`` in order to prevent the Makefile from running
 any bzr commands, all of which access the parent branch over the network.
 Where bzr may have provided information such as the revno, sensible defaults
 are used instead.  As many of these bzr commands are used to populate
 variables regardless of the target, defining NO_BZR will have an effect on
 all targets, except dist, which will refuse to complete.
 
-- Note that this allows one to run any make target from the working copy, 
+- Note that this allows one to run any make target from the working copy,
   even if it is a lightweight checkout, by skipping steps that involve
   network access through bzr.  Because of this, make will assume that
   the revno is 0 and that the branch is clean and up to date without
@@ -279,9 +290,9 @@
 
   - Encourage but do not require each person to mention what card they plan to
     work on for the next 24 hours, if that has not already been discussed.
-  - Ask the person to mention any items that everyone should know: remind people
-    of reduced availability, request help such as code reviews or pair requests,
-    etc.
+  - Ask the person to mention any items that everyone should know: remind
+    people of reduced availability, request help such as code reviews or pair
+    requests, etc.
 
 Checklist for Running a Weekly Retrospective
 ============================================


Follow ups