[Numpy-discussion] Branching 1.1.x and starting 1.2.x development

[Jarrod Millman]

Hello everyone,

In response to some of the recent discussion (and confusion)
surrounding my plan for the trunk and 1.2 development over the next
month or two, I propose the following:

1.  Stay with the "original" plan until Thursday, May 22nd.  That is,
all commits to the trunk should be extremely trivial, bug-fixes for
issues that specifically arise during from the release candidate.  (I
think that there is no need to revert any changes that have happened
on the trunk up to this point, but let's be more conservative going
forward over the next 2 days.)
2.  On Thursday, May 22nd, I will create a 1.1.x branch off the trunk.
 I will tag 1.1.0 off the branch.  The trunk will become open for
development of the 1.2.x series.

Commits to the 1.1.x branch should only be relatively trivial
bug-fixes.  Ideally, 1.1.1 will be practically identical to 1.1.0 with
only a handful of important bug-fixes.  More specifically, this means
that

1. There will be no new features added to the 1.1.x series.
2.  There will be only very minor documentation fixes to the 1.1.x
series.  Only if the documentation has something so incorrect that it
is considered a bug will it be updated.  In particular, most of
Stefan's work will go into 1.2.x.
3.  There will be only very trivial bug-fixes in the 1.1.x series.  I
would expect no more than, say, 10 bug-fixes in a given
micro/maintenance release.  This is just a rule of thumb; but given
our current development size, I would prefer to see most of our effort
focused on the 1.2.x series.  Given that 1.2.0 will be released by the
end of August, this shouldn't cause any major problems for our users.
Moreover, it will help ensure that if they upgrade from 1.1.x to
1.1.x+1 that there will be almost no chance that their code will
break.

Commits to the trunk (1.2.x) should follow these rules:

1.  Documentation fixes are allowed and strongly encouraged.
2.  Bug-fixes are strongly encouraged.
3.  Do not break backwards compatibility.
4.  New features are permissible.
5.  New tests are highly desirable.
6.  If you add a new feature, it must have tests.
7.  If you fix a bug, it must have tests.

If you want to break a rule, don't.  If you feel you absolutely have
to, please don't--but feel free send an email to the list explain your
problem.

In addition to these rules for 1.2 development, let me remind everyone
that we have all ready agreed that 1.2 will:

1.  Use the nose testing framework.
2.  Require Python 2.4 or greater.  This means we have built-in
decorators, set objects, generators, etc.
3.  Contain some planned changes to median and histogram.

I hope this is more clear than the numerous partial emails I sent out
before.  Again let me apologize for the earlier confusion.  Please let
me know if this is a workable plan for you.  In particular, let me
know it there is some aspect of this that you simply refuse to agree
to in at least principle.  Also at this point let's focus on the
overall picture.  Namely, that (1) the trunk is currently is a
relatively hard freeze and that (2) I will create a 1.1.x branch on
Thursday and open the trunk for 1.2 development.  The other details
should be viewed as explanatory narrative that can be refined later.

Unless there are major objections to this proposal, I will take some
time later this week to make this information available on the wiki.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/