On Tue, Jun 26, 2012 at 9:20 PM, Travis Oliphant <[email protected]>wrote:
> > On Jun 26, 2012, at 2:10 PM, Ralf Gommers wrote: > > > > On Tue, Jun 26, 2012 at 5:43 PM, Travis Oliphant <[email protected]>wrote: > >> >> Hey all, >> >> After some more investigation, I'm not optimistic that we will be able to >> get a 1.7 release out before SciPy. I would like to get a beta release >> out by SciPy (or even an rc1 release). But, given the number of code >> changes and differences between 1.5.x and 1.7, I think we will need an >> extended beta release stage for 1.7 that will allow as many users as >> possible to try out the new code base and report back any regressions or >> backward incompatibilities that need to be fixed before the final release. >> > > +1 > > >> The fundamental rule I think we have is that "code depending on NumPy >> that worked with 1.5.x should continue to work with 1.7 without alterations >> required by the user" >> > > The rule should be 1.6.x imho. Undoing things that were changed in between > 1.5.x and 1.6.x makes very little sense; numpy 1.6.0 has been out for over > a year. > > > Unfortunately, I think there are issues we are just now seeing with code > that was released in 1.6.x, and there are many people who have not moved > forward to 1.6.x yet. > Some examples would be nice. A lot of people did move already. And I haven't seen reports of those that tried and got stuck. Also, Debian and Python(x, y) have 1.6.2, EPD has 1.6.1. I think the number of cases we're talking about here is in fact limited. But discussion of those cases is necessary if a change would break 1.6.x. The rule should in fact be that code working with NumPy 1.0 should work > with 1.7 (except for "bug-fixes"). > That's a good rule. Hard to ensure for corner cases which didn't have test coverage though. I realize that with some of the semantics it's going to be hard to be > pedantic about the "rule". But, I'm going to be very responsive to users > of 1.5.x and even possibly 1.3.x who have code issues in trying to move > forward. > > > >> This does not mean we can't add new APIs or deprecate old APIs --- but I >> think that we do have to be much more careful about when deprecated APIs >> become unavailable. There is a lot of code that assumes the current >> API. Both code that is in released packages and code that is in >> "unreleased packages" which we are not even aware of. >> > > I think you are mainly talking here about changes that had unintended > side-effects, and broke things without anyone realizing that in time. If > you read the 1.5.0, 1.6.0 and 1.7.0 release notes, there have been very few > actual deprecations. > > Besides that, we have a long standing policy of removing those things that > do get deprecated after one minor release: > http://projects.scipy.org/numpy/wiki/ApiDeprecation. If you propose to > change that, I suggest discussing it in a separate thread. > > > We need to change that, I think. I feel pretty strongly that we can't > just remove APIs after one minor release after observing more of NumPy's > use in the wild. APIs should exist for at least 5 years and preferably > only change on major releases. > > > >> I don't want to finalize the 1.7 release until we get enough feedback >> from end-users about the impact of all the changes. This will likely take >> a longer beta-release period than usual: certainly not until after SciPy >> where we will make a concerted effort to get people to try the new 1.7 beta >> and report back on the impact on their code-base. >> >> Ondrej is helping out on this effort which I really appreciate. Other >> people who have time to help with the release effort --- especially in >> fixing regressions will be greatly appreciated. >> > > Did you happen to see > https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt? > Among other things, it lists a few things that are still to be done (merge > doc wiki edits, flip the "raise_warnings" switch) and details on the Wine / > MinGW setup that may be useful. I did just spot a mistake there by the way, > we're still on MinGW 3.4.5. > > > It's nice to have a document like this. Of course, I've seen it. I > don't think we will be using Wine and MinGW to do the Windows builds, > though. > Any more details? If you are thinking about using MSVC for numpy, will it work with existing scipy and other binaries? Ralf
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
