Mne-python: MAINT: Release 0.21

[larsoner]

We should cut a release in a few weeks, tentatively scheduled for September 15th. Feel free to tag issues and PRs that realistically can and should make it if you have permissions, and if you don't, feel free to comment on ones that you think should be tagged for 0.21.

[agramfort]

+10 !

[dengemann]

September 15 ? @larsoner

[larsoner]

Whoops, yes I meant Sept 15th :)

[hoechenberger]

We need to draft an announcement. Also with the last release we had this small video clip demonstrating the new Time Viewer. We should do a similar demo of some notable features in 0.21 as well. Which are the most notable new features?

[hoechenberger]

Maybe:

• muscle artifact detection #7407
• improved diploe plotting #8188
• allow renaming of montage channels #7685
• volumetric atlas support #7639
• eSSS #7156
• STC flatmap #8082
• REST #8132
• cov.plot_topomap #8197
• Persyst reading #8176
• Nihon Kohden reading #6017

[cbrnr]

Maybe mne.io.read_raw #7809 is also worth mentioning as a QoL improvement.

[hoechenberger]

From the chanelog:

• Add 'auto' option to mne.preprocessing.ICA.find_bads_ecg() to automatically determine the threshold for CTPS method by Yu-Han Luo
• Add a notebook 3d backend for visualization in jupyter notebook with mne.viz.set_3d_backend() by Guillaume Favelier
• Use PyVista as the default backend for 3D visualization instead of Mayavi by Guillaume Favelier

[larsoner]

• Volumetric 3D rendering (#8064)

[larsoner]

BTW we are not ready to release, I'm still doing battle with CircleCI

[cbrnr]

@hoechenberger since we're already discussing the release, did you have time to work on an mne-base package in conda-forge by any chance? I think this would be pretty useful, because the standard package is really quite bloated if all you need is basic EEG analysis tools.

[hoechenberger]

@cbrnr Yes, in https://github.com/conda-forge/mne-feedstock/pull/37
I stopped at some point, I believe there were some difficulties, but cannot remember any details! Would be happy to try picking this up again. But not before the weekend.

[drammock]

If possible I'd like us to start highlighting the contributions of new-to-mne developers in our release announcements. At a minimum, maybe "there were N contributions from M first-time contributors in this release cycle". Better would be to also give examples and call out their names.

[larsoner]

Maybe we should start this process by bolding the entries in the latest.inc?

[drammock]

That could work, although I wonder if folks read the whole changelog (i.e., would bolding actually increase visibility if it's not being read?)

[larsoner]

Some people might, either way they get more visible and next time it's easier to know which entries we should add based on being from new contributors next time. To be clear, I'm suggesting that we just start by doing the bolding in master (and make this what we try to do going forward) -- the next step is to use this bolding to facilitate adding to the release notes for this release.

[drammock]

Ah, got it. Seems like a good approach

[cbrnr]

Should we also add the related PRs to all new entries? This would be very handy for people who would like to dig into the corresponding code changes.

[larsoner]

Should we also add the related PRs to all new entries? This would be very handy for people who would like to dig into the corresponding code changes.

If someone wants to do this, feel free. I'm not up for it, I suspect it's going to take some time... the fastest way I can think of is to look at the git blame page of our latest.inc and you'll probably get most of the PR numbers from each line, though some will have to be manually adjusted / searched for due to rebases, merges, typo fixes, etc.

Another option going forward in other repos I've used is to have maintainers ensure that the title of the PR is good and that it's tagged with enhancement or bug, and we would probably want to add/use a custom api tag. Then the changelog can be automatically generated before release EDIT: with github changelog generator.

[cbrnr]

I was thinking of adding the PR only for new changes going forward - I wouldn't want to do it for all changes (in 0.21) either. As long as we manually create changelog entries, it should not be too much effort for the contributor to also add the corresponding PR. If there is a way to automatically generate the complete changelog - yes, we should go for it, but this seems like it will probably need more time until it works.

[sappelhoff]

we are doing this "manual" changelog with PR links in MNE-BIDS, see changelog.

I would be in favor of continuing the changelog manually and simply adding a PR link "on top". The effort is low, and the benefit is tangible.

re: automatic changelog generation --> would it save a lot of time? would it be of an equally high quality? ... or will it turn out to be a lot of work for something that's "almost as good as manual"?

[larsoner]

would it be of an equally high quality?

This is an automatically generated one:

https://sphinx-gallery.github.io/stable/changes.html

So basically we would set the PR title to what we want the changelog entry to be, and instead of putting it in a section we tag it with a GitHub label. So the quality depends on how nicely you format your PR titles.

would it save a lot of time?

In general it does save work for contributors because there is no need for rebase/merge due to latest.inc conflicts. For maintainers it only adds a couple minutes during release. So I see it as a net time saver.

One downside I see is that you really only get it on release rather than continuously. But perhaps worse, we would lose the names linking, so probably not worth it

[hoechenberger]

If possible I'd like us to start highlighting the contributions of new-to-mne developers in our release announcements.

I just wanted to share that I very much like this idea, particularly in the context of #8221

[rob-luke]

Which are the most notable new features?

Its probably not as widely used as the features hoechenberger highlighted, but support for NIRS over 0.20 and 0.21 has increased. Slight bias here.