various updates

[roundup.git] / doc / developers.txt

diff --git a/doc/developers.txt b/doc/developers.txt
index b633bf88fa71582b97311123177cba0ae12f7191..d49dba37303aab48e4ee6482c473a81952d16107 100644 (file)
--- a/doc/developers.txt
+++ b/doc/developers.txt
@@ -1,7 +1,8 @@
+==================
 Developing Roundup
 ==================
 
-:Version: $Revision: 1.1 $
+:Version: $Revision: 1.6 $
 
 Note: the intended audience of this document is the developers of the core
 Roundup code. If you just wish to alter some behaviour of your Roundup
@@ -13,7 +14,7 @@ Getting Started
 ---------------
 
 Anyone wishing to help in the development of Roundup must read `Roundup's
-Design Document`_.
+Design Document`_ and the `implementation notes`_.
 
 All development is coordinated through two resources:
 
@@ -34,15 +35,72 @@ CVS Access
 
 To get CVS access, contact richard@users.sourceforge.net.
 
-Developers with CVS access should follow these simple guidelines:
+CVS stuff:
+
+1. to tag a release (eg. the pre-release of 0.5.0)::
+
+    cvs tag release-0-5-0-pr1
+
+1. to make a branch (eg. branching for code freeze/release)::
+
+    cvs co -d maint-0-5 -r release-0-5-0-pr1
+    cd maint-0-5 
+    cvs tag -b maint-0-5
+
+2. to check out a branch (eg. the maintenance branch for 0.5.x)::
+
+    cvs co -d maint-0-5 -r maint-0-5
+
+3. to merge changes from the maintenance branch to the trunk, in the
+   directory containing the HEAD checkout::
+
+    cvs up -j maint-0-5
+
+   though this is highly discouraged, as it generally creates a whole swag
+   of conflicts :(
+
+Standard tag names:
 
+*release-maj-min-patch[-sub]*
+  Release of the major.minor.patch release, possibly a beta or pre-release,
+  in which case *sub* will be one of "b*N*" or "pr*N*".
+*maint-maj-min*
+  Maintenance branch for the major.minor release. Patch releases are tagged in
+  this branch.
+
+Typically, release happen like this:
+
+1. work progresses in the HEAD branch until milestones are met,
+2. a series of beta releases are tagged in the HEAD until the code is
+   stable enough to freeze,
+3. the pre-release is tagged in the HEAD, with the resultant code branched
+   to the maintenance branch for that release,
+4. bugs in the release are patched in the maintenance branch, and the final
+   and patch releases are tagged there, and
+5. further major work happens in the HEAD.
+
+Project Rules
+-------------
+
+Mostly the project follows Guido's Style (though naming tends to be a little
+relaxed sometimes). In short:
+
+- 80 column width code
+- 4-space indentations
+- All modules must have a CVS Id line near the top, and a CVS Log at the end
+
+Other project rules:
+
+- New functionality must be documented, even briefly (so at least we know
+  where there's missing documentation) and changes to tracker configuration
+  must be logged in the upgrading document.
 - subscribe to roundup-checkins to receive checkin notifications from the
   other developers with CVS access
 - discuss any changes with the other developers on roundup-dev. If nothing
   else, this makes sure there's no rude shocks
-- run pychecker over changed code
 - write unit tests for changes you make (where possible), and ensure that
   all unit tests run before committing changes
+- run pychecker over changed code
 
 The administrators of the project reserve the right to boot developers who
 consistently check in code which is either broken or takes the codebase in
@@ -56,3 +114,4 @@ Back to `Table of Contents`_
 .. _`Table of Contents`: index.html
 .. _`Customising Roundup`: customizing.html
 .. _`Roundup's Design Document`: spec.html
+.. _`implementation notes`: implementation.html