Remove the release.py module and just use the field in app.yaml.template.
authorTodd Larsen <tlarsen@google.com>
Thu, 26 Feb 2009 04:29:56 +0000
changeset 1502 2fee94feef59
parent 1501 3601ddfe785a
child 1503 c8ebaacc2337
Remove the release.py module and just use the field in app.yaml.template. This is a DRY fix, to have the release /branches/ and /tags/ use a release version that is compatible with the app.yaml file "version:" field. Also, the steps for creating a release were simplified (with several steps removed), and the release procedure moved to app/README, since app/soc/release.py is now deleted. Patch by: Todd Larsen Review by: to-be-reviewed
app/README
app/app.yaml.template
app/soc/release.py
app/soc/views/helper/responses.py
--- a/app/README	Wed Feb 25 20:42:46 2009 +0000
+++ b/app/README	Thu Feb 26 04:29:56 2009 +0000
@@ -1,3 +1,5 @@
+= WHAT BELONGS IN trunk/app =
+
 trunk/app should contain only the files needed for the actual Google App
 Engine application "image".  Support code that is not part of the application
 image belongs elsewhere, such as in trunk/scripts, for example.
@@ -29,3 +31,69 @@
 and add the package name as a suffix (LICENSE.django is an example of this
 case).
 
+= CREATING AN OFFICIAL RELEASE =
+
+== CREATING THE RELEASE CANDIDATE BRANCH AND TAGGING A RELEASE ==
+
+Steps (currently done by hand, but too be scripted in the future) to make
+a release:
+
+1) Set the "version:" field in the app.yaml.template file to a "release
+   candidate" release string.  Version strings cannot contain dots
+   (periods) and have some other restrictions.  As a result, the format
+   of the release-candidate "version:" field needs to be:
+
+     A-B-YYYYMMDD
+
+   where:
+   * A is a major number (currently '0' until at least GSoC functionality
+     is completely implemented)
+   * B is a (possibly multi-digit) minor number that is increased whenever
+     there is a major increase in functionality (some major GSoC or GHOP
+     feature, e.g. student sign-ups and proposals, is implemented)
+   * YYYY is the four digit year of the release date
+   * MM is the (always) two digit month of the release date (zero-padded)
+   * DD is the (always) two digit day of the release date (zero-padded)
+
+2) Commit this file *by itself* in its own commit.
+
+3) Use 'svn cp' to create a release branch of /trunk/ in /branches/ with
+   exactly the same name as the contents of the "version:" field in the
+   app.yaml.template file.  Branch on the specific revision of the commit
+
+4) Finalize the release candidate branch for a push to the live web site.
+   Use 'svn cp' to create a tag in /tags/ with exactly the same name as the
+   contents of the "version:" field in the app.yaml.template file.  Specify
+   the *specific revision* of the commit in step #2 above.
+
+Step #4 might actually be delayed for one or more patch releases, once there
+is some sort of User Acceptance Testing (UAT) checklist for a release
+candidate, because defects would be patched in the release candidate branch
+one or more times before an actual release is tagged.  See the next section
+for details.
+
+== PATCHING AND RE-RELEASING AN EXISTING RELEASE CANDIDATE BRANCH ==
+
+To re-release a previously-tagged release branch after a patch for a push to
+the live web site:
+
+1) Increment the "patch suffix" of the "version:" field value to the next
+   integer (for example, "p1" becomes "p2"), or append "p1" to the end of
+   the existing string if this is the first patch release (so the first tagged
+   patch release will always be "p1").  For example:
+
+     A-B-YYYYMMDD becomes A-B-YYYYMMDDp1
+
+   and:
+
+     A-B-YYYYMMDDp1 becomes A-B-YYYYMMDDp2
+
+   etc.
+
+2) Commit this file *by itself* in its own commit (after the last batch
+   of patches being made to the existing /branches/ release branch).
+
+3) Use 'svn cp' to create a tag in /tags/ with exactly the same name as the
+   contents of the new, patched "version:" field in the app.yaml.template
+   file.  Specify the *specific revision* of the commit in step #2 above.
+
--- a/app/app.yaml.template	Wed Feb 25 20:42:46 2009 +0000
+++ b/app/app.yaml.template	Thu Feb 26 04:29:56 2009 +0000
@@ -14,7 +14,8 @@
 
 # TODO(proto): uncomment and supply a Google App Engine application instance
 # application: FIXME
-version: 1
+# TODO(release): see the instructions in README about the "version:" field
+version: 0-5-20090224
 runtime: python
 api_version: 1
 
--- a/app/soc/release.py	Wed Feb 25 20:42:46 2009 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,65 +0,0 @@
-# Copyright 2008 the Melange authors.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-"""Release tag string for display in templates (and possibly other uses).
-
-Steps (currently done by hand, but too be scripted in the future) to make
-a release:
-
-1) set RELEASE_TAG in this file to a "release candidate" release string that
-   ends in "rc"
-
-2) commit this file *by itself* in its own commit
-
-3) use 'svn cp' to create a release branch in /branches/ with exactly the
-   same name as the contents of the RELEASE_TAG string
-
-4) set RELEASE_TAG back to None in /trunk/
-
-
-To finalize a release candidate in a release branch for a push to the live
-web site:
-
-1) in the release branch, change RELEASE_TAG to remove the trailing "rc"
-
-2) commit this file in the release branch *by itself* in its own commit
-
-3) use 'svn cp' to create a tag in /tags/ with exactly the same name as the
-   contents of the RELEASE_TAG string
-
-4) put the release branch in a state where it is ready for additional patches
-   after the tag by setting the end of the RELEASE_TAG string to "p0"
-
-
-To re-release a previously-tagged release branch after a patch for a push to
-the live web site:
-
-1) increment the "patch suffix" of the RELEASE_TAG string to the next integer
-   (for example, "p0" becomes "p1", so the first tagged patch release will
-   always be "p1", not "p0", which is just a placeholder)
-
-2) (same as #2 for a release candidate)
-
-3) (same as #3 for a release candidate)
-
-4) (there is no step 4)
-"""
-
-__authors__ = [
-  '"Todd Larsen" <tlarsen@google.com>',
-  ]
-
-
-RELEASE_TAG = None
-
--- a/app/soc/views/helper/responses.py	Wed Feb 25 20:42:46 2009 +0000
+++ b/app/soc/views/helper/responses.py	Thu Feb 26 04:29:56 2009 +0000
@@ -29,7 +29,6 @@
 from django import http
 from django.template import loader
 
-from soc import release
 from soc.logic import accounts
 from soc.logic import system
 from soc.logic.models import site
@@ -128,8 +127,9 @@
 
   context['sidebar_menu_items'] = sidebar.getSidebar(account, user)
 
-  context['soc_release'] = release.RELEASE_TAG
-  context['gae_version'] = system.getAppVersion()
+  gae_version = system.getAppVersion()
+  context['gae_version'] = gae_version
+  context['soc_release'] = gae_version.split('.', 1)[0]
 
   settings = site.logic.getSingleton()