[Numpy-svn] r6501 - trunk/doc/release
Fri Feb 27 01:21:14 CST 2009
Date: 2009-02-27 01:21:09 -0600 (Fri, 27 Feb 2009)
New Revision: 6501
Start the proposal for time-based release.
--- trunk/doc/release/time_based_proposal.txt 2009-02-27 04:50:13 UTC (rev 6500)
+++ trunk/doc/release/time_based_proposal.txt 2009-02-27 07:21:09 UTC (rev 6501)
@@ -0,0 +1,96 @@
+This document proposes some enhancements for numpy and scipy releases.
+Successive numpy and scipy releases are too far appart from a time point of
+view - some people who are in the numpy release team feel that it cannot
+improve without a bit more formal release process. The main proposal is to
+follow a time-based release, with expected dates for code freeze, beta and rc.
+The goal is two folds: make release more predictible, and move the code forward.
+Right now, the release process of numpy is relatively organic. When some
+features are there, we may decide to make a new release. Because there is not
+fixed schedule, people don't really know when new features and bug fixes will
+go into a release. More significantly, having an expected release schedule
+helps to *coordinate* efforts: at the beginning of a cycle, everybody can jump
+in and put new code, even break things if needed. But after some point, only
+bug fixes are accepted: this makes beta and RC releases much easier; calming
+things down toward the release date helps focusing on bugs and regressions
+The proposed schedule is to release numpy every 3 months - the exact period can
+be tweaked if it ends up not working as expected. There will be several stages
+for the cycle:
+ * Development: anything can happen (by anything, we mean as currently
+ done). The focus is on new features, refactoring, etc...
+ * Beta: no new features. No bug fixing which requires heavy changes.
+ regression fixes which appear on supported platforms and were not
+ caught earlier.
+ * Polish/RC: only docstring changes and blocker regressions are allowed.
+The schedule would be as follows:
+ | Week | 1.3.0 | 1.4.0 | Release time |
+ | 1 | Development | - | |
+ | 2 | Development | - | |
+ | 3 | Development | - | |
+ | 4 | Development | - | |
+ | 5 | Development | - | |
+ | 6 | Development | - | |
+ | 7 | Beta | - | |
+ | 8 | Beta | - | |
+ | 9 | Beta | - | 1.3.0 released |
+ | 10 | Polish | Development | |
+ | 11 | Polish | Development | |
+ | 12 | Polish | Development | |
+ | 13 | Polish | Development | |
+ | 14 | | Development | |
+ | 15 | | Development | |
+ | 16 | | Beta | |
+ | 17 | | Beta | |
+ | 18 | | Beta | 1.4.0 released |
+Each stage can be defined as follows:
+ Development Beta Polish
+ Python Frozen: - slushy Y
+ Docstring Frozen: - slushy thicker slush
+ C code Frozen: - thicker slush thicker slush
+ * slushy: you can change it if you beg the release team and it's really
+ important and you coordinate with docs/translations; no "big" changes.
+ * thicker slush: you can change it if it's an open bug marked
+ showstopper for the Polish release, you beg the release team, the
+ change is very very small yet very very important, and you feel
+ extremely guilty about your transgressions.
+The different frozen states are intended to be gradients. The exact meaning is
+decided by the release manager: he has the last word on what's go in, what
+The proposed schedule means that there would be at most 4 months between
+putting code into the source code repository and being released.
+For every release, there would be at least one release manager. We propose to
+rotate the release manager: rotation means it is not always the same person
+doing the dirty job, and it should also keep the release manager honest.
More information about the Numpy-svn