On Sun, May 11, 2008 at 9:42 PM, David Cournapeau
<cournapeau@cslab.kecl.ntt.co.jp> wrote:
> My impression, but maybe I am missing something, is that the release
> slipped because everybody added new code. If we have a strict policy to
> say no new code, only bug fixes at least for 2 weeks before a release
> (and even no changes at all for a period), the release process becomes
> much easier, no ?
Yes and no. The addition of MaskedArrays, which was merged in
February, has been one of the issues that has delayed the release. So
it would probably been a good idea to release 1.0.5 before the merge,
but the trunk had several other blockers at that point. In early
March you may remember that there were several problems showing up on
buildbot that were unrelated to MaskedArrays.
The matrices issue has been more of a non-issue than all the list
traffic might suggest. I wasn't waiting for it it to be resolved
before releasing and no that I am ready to release, I plan to leave
matrices just as they were (including not adding any
DeprecationWarnings).
I could be wrong but I am pretty certain that there has mostly been
bugfixes, tests, and documentation since MaskedArrays was merged in
February excepting, perhaps, the histogram change.
> IMHO, the main advantage of time-based release is to be able to say no
> to new code just before release, and to be able to say that an api
> breaks cannot happen between two releases: any change needs at least N
> releases in between with warnings, and we know what N means because N *
> release period is the time you have to make changes if you want to stay
> up to date.
I agree, but we also have the problem that we don't have adequate
tests. I don't think we realized the extent to which MaskedArrays
necessitated code rewrites until Charles Doutriaux pointed out how
much difficulty the change was causing to their code base.
So, and I know David agrees, in addition to a time-based release, we
need to make a better effort to improving our unit tests. I think
that main thing we should focus on for 1.2 is moving to nose as our
testing framework and writing many more unit tests.
> I personally really did not like what happened with ma and matrix in the
> 1.1, and I would like to avoid this in the future. It is already pretty
> bad to break code in a minor release, but to do it without warnings is
> really something which should never happen again IMHO.
I agree with your concern about MaskedArrays, but I also hope that the
new implementation has fixed more issues than it has caused. I have
to admit that I didn't really understand how big of an impact the ma
changes would have. I should have paid closer attention and raised
more of an alarm. Sorry, mea culpa. Despite the concern that has
been raised because of the ma change, I am still confident that this
release is extremely solid--there have been an amazing amount of
bugfixes, new tests, and new documentation. I believe we are moving
forward and am happy that there is a push to do even better.
Just to be clear, there isn't going to be any changes to matrices in
the 1.1 release. I am not even going to allow warnings, because I
haven't been convinced that there is anything close to an agreement
about what, if anything, is going to change. It is also clear that if
there is any change to matrices, there will have to be a staged
migration. There may be a new matrix class released in 1.2 along with
the old one. We can talk about the details of that change later,
since there are some very strong feelings about this one issue. I
don't want this discussion to get hijacked like my email thread for
finalizing the 1.1 release.
PS. David you are now officially my release co-deputy for the 1.2
release for August. We will be in 'feature-freeze" on August 1st and
will have a coding sprint during the summer conference to finalize the
release. The major changes that I anticipate are:
1. moving to the nose testing framework
2. major revamping of the documentation thanks to Stefan and Joe.
3. the planned changes to median and histogram
4. possibly a technology preview of a new matrix class.
5. and a move to a time-based release
After the 1.2 release we will revisit the time- vs. feature-based
release systems. I have been planning to move to a time-based release
and with David's help, I am confident that we can pull it off.
Thanks,
--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/