Regular release cycle

[haesleinhuepf]

Hi all,

following up earlier discussions and issues, e.g. #4119, BiAPoL/napari-clusters-plotter#35 (comment) , I'm suggesting a regular release cycle for napari.

Rationale:

• From the perspective of plugin developers it's not very nice when plugins suddenly break because there was a new release of napari.
• Napari-releases are typically announced about a week in advance, which makes it very hard for plguin developers to react in time to recent changes.
• Many plugin developers are not in zulip and thus, may not receive notifications about a new upcoming release at all.
• Documentation for transitioning between napari-API versions is not easy to find.
• I made very good experience with an annual release cycle in the clij project. Users appear happy, too, because the API appears stable to them.
• The Fiji community made good experience with releases following hackathons. Early Fiji versions were even called after the town where the developers met.

Benefits. This would allow us:

• predict when plugins could potentially break,
• predict when deprecated methods are removed,
• plan long-term when to test things and release plugin updates,
• organize hackathons and testathons just before a new release. (community building)

Maybe we could think of a regular release cycle every 3, 4 or 6 months.

I'd be glad to hear opinions. @tlambert03 @jni @sofroniewn @neuromusic @kevinyamauchi @Czaki @alisterburt @brisvag

Thanks!
Robert

[jni]

Hi again @haesleinhuepf! In fact we have been discussing this very topic in the developer meetings! @sofroniewn was supposed to add the next release to the calendar but I guess it got buried under other responsibilities. 😜 Anyway, we are planning on a 2-month release cycle at first, with release candidates the first Tuesday of odd-numbered months, and releases a week after that. That might still be too fast, but we definitely agree that the regularity will help. If we find that it's still too frequent, we are definitely prepared to slow it down.

Thanks for raising the issue!

[haesleinhuepf]

That might still be too fast

No problem. Some of us can then just ignore the odd releases and stick to the even ones. 😁
Thanks for making this happen! Key is predictability of events. 🙌

[Czaki]

If I good remember there was a discussion about this and there was a decision that the main release will be every 2 months (and after this in 2-3 weeks there will be bugfix release).

The big problem is that every release is "all hands on deck" for one week when only testing and stop development process. Maybe helpful will be create release branch and make the process of prepare release a little longer.

Also I would like to remind that napri publish alpha releases on pypi few days before release. So if One have automated CI with daily running --pre test then one will be inform that something is broken. It is often possible to change API break into API deprecation.

Having feedback loop is really helpful when working on stable API. Sometimes API changes are enforced by users (npe1 to npe2 transition because of importing heavy modules by plugin creators).

[sofroniewn]

Agreed with all this - I have added to calendar now

Would be nice to make another topline section called releases (cc @codemonkey800 @isabela-pf) - right now they appear under other meetings.

I've added rc and release dates for March and May, first and second tuesdays of the month respectively. This puts us on a 2 month release cycle. I think bug fix releases aren't something we plan for - but are something we are open for.

[neuromusic]

Would be nice to make another topline section called releases

Created an issue to track this: https://github.com/napari/napari/issues/4143

[kevinyamauchi]

I am excited we are moving towards a more regular release cycle. Thanks for the discussion, everyone! 🚀

[sofroniewn]

It would be great if someone could volunteer to be the release manager for the next release. @alisterburt did it last time, maybe he wants to do it again to get some continuity of experience going? Maybe someone else can volunteer to assist (cc @kevinyamauchi @andy-sweet).

Here is our official release guide. We might want to update with concept of a release manager who's additional responsibilities include:

~ 1 week before rc looking through currently open PRs and getting a sense of what would be good to have merged before the rc (bug fixes should try and go in, features that are close to landing etc.) and following up with some PR authors/ reviewing/ merging as needed.
~ 1 week before creating zulip thread in release channel letting people know rc is coming and calling out some PRs that would be nice to get in before then
~ 2 days before rc autogenerating release notes with script and making a PR. At this point the release manager should really now be the only person merging PRs on the repo for the next week.
~ day of rc release, add any recently merged PRs to release notes, merge release notes and make rc. Announce to release stream on zulip that first rc is available for testing
~ during week following rc, the rc manager should be responsible for merging any PRs to repo - mainly focused on regressions and bug fixes. new features should wait till after release. release notes should be updated accordingly. at reasonable times after merging PRs a new rc should be made and announced on zulip
~ day of release, make sure final rc has been tested, all PRs have been added to release notes and then make release and announce on zulip

the above is a little rough, but maybe we add that to release guide once we like it

[andy-sweet]

It would be great if someone could volunteer to be the release manager for the next release. @alisterburt did it last time, maybe he wants to do it again to get some continuity of experience going? Maybe someone else can volunteer to assist (cc @kevinyamauchi @andy-sweet).

I'd be happy to assist with a release, but I'm out this week, so it looks like that won't quite work for the next RC?

[alisterburt]

Bit late to the party here - I agree with all of the above, regular releases feel important and exciting!

@sofroniewn I've made #4139 to document the process based on your notes, thank you!

Unfortunately I can't commit to managing the release in March - I would be happy to take it on as a regular responsibility from May though, ideally with some assistance in case things come up 🙂

[sofroniewn]

All good - thanks for weighing in. I'm not sure then if @kevinyamauchi wants to take lead - or maybe @tlambert03 can take lead this time?

[jni]

Happy to take this one, especially thanks to the detailed guides put together by @sofroniewn and @alisterburt! 😊

Incidentally, we need to apply the theme to the new docs and deploy the new docs. I can't get that working locally unfortunately — even after pip installing napari-sphinx-theme, I get a no theme named 'napari-sphinx-theme' found (missing theme.conf?) error. (Also no theme named 'napari_sphinx_theme' found (missing theme.conf?), tried both.) @codemonkey800 @tlambert03, ideas here? Is there perhaps a missing file in the theme as packaged for PyPI?

[jni]

I'll make an issue, just thought of this while looking at the release docs and considered "missing PRs for release"

[jni]

see #4147

[sofroniewn]

Great, thanks for stepping up @jni!! Agreed it we should have docs ready for this rc. I'm not sure if we'll need to delay the rc date to make it possible - I don't think so, but @neuromusic would know