On Fri, May 16, 2008 at 12:20 AM, Jarrod Millman <[hidden email]> wrote:
> I believe that we have now addressed everything that was holding up
> the 1.1.0 release, so I will be tagging the 1.1.0rc1 in about 12
> hours. Please be extremely conservative and careful about any commits
> you make to the trunk until we officially release 1.1.0 (now may be a
> good time to spend some effort on SciPy). Once I tag the release
> candidate I will ask both David and Chris to create Windows and Mac
> binaries. I will give everyone a few days to test the release
> candidate and binaries thoroughly. If everything looks good, the
> release candidate will become the official release.
> Once I tag 1.1.0, I will open the trunk for 1.1.1 development. Any
> development for 1.2 will have to occur on a new branch. I also plan
> to spend sometime once 1.1.0 is released discussing with the community
> what we want included in 1.2.
Since there seems to be some confusion about what should be happening
and where, I wanted to clarify the situation. There is currently no
branch for 1.1.x; the trunk is still officially the 1.1.x "branch". I
have tagged a 1.1.0rc1 off the trunk for testing. A development
freeze is in effect on the trunk for a few days. I plan to release
1.1.0 officially be this Friday unless something ugly shows up.
I know this is frustrating for some of you, but please just bear with
me for a few days and help me try and get a stable 1.1.0 out as fast
as possible. The only things that should be committed to the trunk
now should be trivial bug-fixes to specific issues found by the
A good example of the kind of change I intended on the trunk right now
is Robert Kern's fix to two tests that were incorrectly assuming
http://projects.scipy.org/scipy/numpy/changeset/5196 In fact, this is exactly the type of thing I was hoping we might
uncover by creating binaries for the release candidate.
So if you want to help get NumPy 1.1.0, please test the release
candidate as well as the release candidate binaries. Also please use
restraint in making new commits. I don't have time to police ever
commit, so I am asking everyone to just use their best judgment.
Please be patient, the release will be out very soon.
Jarrod Millman wrote:
> I know this is frustrating for some of you, but please just bear with
> me for a few days and help me try and get a stable 1.1.0 out as fast
> as possible. The only things that should be committed to the trunk
> now should be trivial bug-fixes to specific issues found by the
> release candidate.
Ok, that should have be more explicit before, I think, because it was
not obvious at all. I did a few commits: should I revert them ?
It is too late for this release, but why didn't you create a 1.1.0
branch ? That way, only the release manager has to do the work :) More
seriously, I do think it is more logical to branch the trunk for a
release, specially in the svn trunk/branches/tags model, and I think we
should follow this model for the next releases.
On Tue, May 20, 2008 at 12:50 AM, David Cournapeau
<[hidden email]> wrote:
> Ok, that should have be more explicit before, I think, because it was
> not obvious at all. I did a few commits: should I revert them ?
Sorry I wasn't more clear; I think we could avoided a lot of
confusion, if I had done a better job explaining what I meant.
Anyway, I don't think there is a need to revert any of the changes
that have gone in all ready. I took a quick look at ever change that
has been made over the last few days and I didn't see anything that I
believe will break anything. If anyone notices something that I have
overlooked which should be removed, please let me know ASAP. Also
let's be extremely careful about committing to the trunk over the next
two to three days.
So, I tried something different this time. I actually would prefer to
follow the conventional svn trunk/branches/tags model--as long as
everyone else is willing to follow it. After all, I actually voted
for it before I vote against it. I will send out an email momentarily
proposing something closer to this. Please respond to my next email
and not this one.