[Twisted-Python] Remember the thing about Jack and the releasing and the software? Yeah.

[Glyph Lefkowitz]

So, I finally managed to kick 0.10.0 out the door, and it didn't even bite
me on the way out (yet).  However, I think that this release indicates the
need for a more defined release process.  (This one's for you, Moshe.)

As part of the release this time, I wrote some automated acceptance tests
to help me run the gauntlet of testing web/reality/tap
building/words/manhole/telnet... these were really helpful, and helped
dash & I squash at least one bug that we probably wouldn't have known
about otherwise :-).

So, here's a proposal for a test-and-release plan:

---

Step 1: discuss features and declard dates

Mailing list discussion of what features are going in to the next release.  
People give estimates for the associated tasks, and a release date is set.

Step 2: ensure compatibility

3 days away from the release date, development should be finishing on all
features desired.  In cases where it's not, those features will be omitted
from the release (and hopefully the developers responsible for them
haven't broken anything in CVS).  At this point, we will take 1 day to
make sure that older versions of data still load properly. (more on this
in a later email) If possible (fingers crossed here) we handle out-of-date
documentation.

This step can be skipped if we don't have any data format changes.

Step 3: acceptance testing

2 days before the release date, we enter a code freeze and everybody runs
the acceptance tests to make sure that everything still works.  If unit
tests run and 3 people sign off on the acceptance tests working (in posts
to the mailing list) this step is over.

Step 4: covering my ass

One day before the release date, we make a release of the software and
upgrade twistedmatrix.com to use it.  This step lasts as long as it takes
to run the site for a 24 hrs with no problems :)

Step 5: release!

With the website (and various other publicly acessible things) in order,
publish the release to Freshmeat.

---

The 3 goals of this strategy are to follow the XP "always have working
code" rule, try to prevent releases from getting held up by a particular
feature if there are other things worth releasing, and give ourselves
confidence and give the world at large a really positive impression of how
robust Twisted is.

Feedback appreciated.

                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://twistedmatrix.com/users/glyph