Gecko [ 122.154.134.11 ]

Name	Size	Permission
docs-f2py	[ DIR ]	drwxr-xr-x
1.3.0-notes.rst	9.83 KB	-rw-r--r--
1.4.0-notes.rst	9.03 KB	-rw-r--r--
1.4.1-notes.rst	567 B	-rw-r--r--
COMPATIBILITY	1.58 KB	-rw-r--r--
DEV_README.txt	687 B	-rw-r--r--
LICENSE.txt	1.51 KB	-rw-r--r--
README.txt	783 B	-rw-r--r--
THANKS.txt	3.04 KB	-rw-r--r--
site.cfg.example	4.89 KB	-rw-r--r--
time_based_proposal.rst	6.54 KB	-rw-r--r--

Code Editor : time_based_proposal.rst

.. vim:syntax=rst

Introduction
============

This document proposes some enhancements for numpy and scipy releases.
Successive numpy and scipy releases are too far apart 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 predictable, and move the code forward.

Rationale
=========

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

Proposal
========

Time schedule
-------------

The proposed schedule is to release numpy every 9 weeks - 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:

Terminology:

* 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
doesn't.  The proposed schedule means that there would be at most 12 weeks
between putting code into the source code repository and being released.

Release team
------------

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.

References
==========

* Proposed schedule for Gnome from Havoc Pennington (one of the core
          GTK and Gnome manager):
          http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
          The proposed schedule is heavily based on this email

* http://live.gnome.org/ReleasePlanning/Freezes

${this.title}

Code Editor : time_based_proposal.rst