0.13.0 release

[FFY00]

Continuing the conversation from #348.

I think, for the new release, #370 and #371 must be sorted out.

When I talked with @rgommers, we decided #348 should also go into the release, that's why I marked it as a release blocker. Unlike the other two issues mentioned above, it doesn't necessarily need to go into 0.13.0, so since this has been brought up in #348 (comment), I am opening this issue to discuss it.

[rgommers]

I will edit the comment and title to reflect that this is about 0.13.0, not 0.14.0. I'll add some more comments later this morning. Please give me a bit of time for that.

[FFY00]

Yes, sorry, this is about 0.13.0.

[rgommers]

In general, what we want from a release is:

1. No regressions
2. Include bug fixes, new features accompanied by docs, and other maintenance work, docs and anything else that is merged.

We'd like main to always be in a releasable state, which is usually the case barring unforeseen regressions that are reported after we merge something. And then fixing that is a top prio.

For this release, the regression related to MSVC that gh-371 fixes is a clear blocker, and we all agree on that. Furthermore, we need to update the docs for the main new feature (editable installs), that's gh-369. Basically everything else is nice to have I believe (also the build dir name for editable installs, that's a really minor thing when you take a step back, and would be completely fine to change in 0.14.0). Several bug fixes are close to the finish line and we'd like to include them, but if they miss 0.13.0 and we release them in 0.13.1 or 0.14.0 shortly after, that doesn't seem like the end of the world. We can release one of those within 1-2 weeks of 0.13.0, that would not be a problem. We don't want to turn into setuptools-style practices with 67 major release and a minor/bugfix release every week, but we're very far from that territory right now:)

There's different things folks want to go into this release. It seems like there's no need to either mark those as must-have (unless they meet the "blocker due to regression, docs for feature, or main isn't releasable" criterion). On the other hand, if a maintainer wants to add their issue/PR to a milestone as an indication of priority is fine I'd say. They're fine to review/merge, and there's no real need to block merging them when they are ready for final review and CI is green (unless they get main into an unreleasable state or are very risky).

It seems to me like @FFY00 and @dnicolodi both have multiple PRs open that they'd like to get merged. Which takes time and review, and updates if there's merge conflicts. But it seems to be more constructive to me to just let them progress at their own pace at this point, and only take priority decisions if really necessary. If you think that's the case, I suggest indicating that with "I think this is too risky or will block release" (this should be quite rare). At the moment I have no PRs open, and do have an interest in getting 0.13.0 out the door. So let me volunteer to make editorial decisions on inclusion/exclusion if one of you deems that necessary - I'd prefer that over continuing disagreement. I do have a large NumPy 2.0 developer meeting on Monday and a proposal deadline on Wednesday, so it's crunch time, but I can/will make PR review and unblocking things a priority next to those things. Nothing is on fire so badly that we really need to ship a release by a certain deadline.

[dnicolodi]

@FFY00 opened this issue because I proposed dropping #348 from the 0.13.0 release. I proposed that because @FFY00 comments on that and other PRs like #364 made it sound like there is some urgency in having a release out of the door very soon. It seems that we don't need to rush. Yet, I agree that having a new release soon with the improvements already merged in main is desirable.

I agree with @rgommers I would be happy with releasing current main plus #371 and updated documentation as per #369. It would also be nice to find consensus on #370 and don't have to release 0.13.0 with a default editable build directory different from what will be used in 0.14.0. I think that a release with these issues covered could be safely be cut next week.

I would leave #348 and #364 for 0.14.0 even as main focus. I think the two PR go together and a real fix for install_subdir() excludes requires solving a bug in Meson that I just started to analyze, see mesonbuild/meson#11599

[rgommers]

A regression with Meson 1.1.0 was just reported for sudo pip install usage - see mesonbuild/meson#11665. The fix is in main, but not in 0.12.1.

I would leave #348 and #364 for 0.14.0 even as main focus

This still seems okay, right @dnicolodi? You just opened gh-387 which is nice to take along. And then we may be good to go for 0.13.0?

[dnicolodi]

I think we want to update the documentation as per #369 before the release, too. I have a local branch where I started to work on it. If we want 0.13.0 out ASAP, I would at least like to get the main points about editable installs right before.

[dnicolodi]

Just to avoid duplicate work: I've already started to prepare the release notes for 0.13.0. I meant to finish today and send a PR, but real work got in the way.

[rgommers]

Great, thanks for that - both for working on it and the heads up (I hadn't started, but did think about it).

[rgommers]

So docs left only at this point it seems - that's progress:)

[rgommers]

Okay, let's call the current state of main good, I'll work on the actual release.