v0.10 planning

[larsoner]

We currently plan to release 0.10 at the end of this month (Sept 30th). Looks like we have a lot of issues marked for 0.10:

https://github.com/mne-tools/mne-python/milestones/0.10

How much time will people have to devote to a release in the next four weeks? Perhaps we should start assigning issues to people. Does someone else want to take over as the release manager for this one?

[dengemann]

We should just release. What is not merged until one week before the release will be automatically shifted to the next cycle. It would be nice to use the new version of MNE for courses that I will give in the last week of September and in the first week of October. But of course, let's see how it goes and what is possible. I'm happy to share release manager tasks, but around the relase it might be difficult for me due to traveling. At least that's not so predictable.

[dgwakeman]

Can I please suggest it be called 1.0? I have the following comments supporting this style:

• Mathematically, logically, and visually it looks stupid to have a 0.10 release following a 0.9
• We actually have the full base feature set of MNE-C implemented now with @Eric89GXL BEM addition
  • Meaning people can do a full forward inverse solution using no MNE-C functions.
  • and I am aware of no functionality, which one can do in MNE-C that can't be done in mne-python at this point

[dengemann]

I understand what you suggest and why you do so. But this is not the version convention typically used in the scientific Python world, see sklearn 0.16.1, also numpy, scipy, etc. I would stick with that.

[teonbrooks]

curious, at what point do we actually bump up the version number leading digit?

[dengemann]

curious, at what point do we actually bump up the version number leading digit?

maybe when numpy, scipy and sklearn do it :smile_cat:

[larsoner]

+1 for doing it once we actually have all the mne-C functionality, including e.g. interactive browsing and coreg and we (Python devs) are all using those instead of the C tools.

[larsoner]

So... take from that what you will regarding an actual timeline :)

[teonbrooks]

ok, maybe it's the linguist in me but I still feel like the method preload_data is a misnomer. The concept of preload makes sense when the object is being constructed, it's before you might actually load it. Once the object is created, you cannot preload it anymore, you can only load the data. I propose that preload_data be renamed load_data since this is actually what it is doing. also since it was added during this dev cycle, if we rename it, there would be no deprecation, just devs would have to adjust. just my 2c.

[dengemann]

preload_data be renamed load_data since this is actually what it is doing. also since it was added during this dev cycle, if we rename it, there would be no deprecation, just devs would have to adjust. just my 2c.

You MMN is so loud that the earth is shaking in Paris. Or maybe it's the Metro. Go for it you've got my blessing.

[larsoner]

I actually don't think of it as being all that different from the preload=True arguments in our constructors. The loading could still come before other processing (and probably does in most cases), so it's not entirely a misnomer in my mind. So from me it's a -1 on the change to keep consistency with preload=True arg and a +0.5 for the fact that it isn't necessarily "pre" anything else, so -0.5 total from me.

[wmvanvliet]

Don't forget the docs! We can move to 1.0 only if all the functionality is there.... and documented!

[larsoner]

Closing for actual open issues