Hi team
Yt 4.0.0 was released on July the 6th of last year, and there’s been a bunch of contributions since then.
I would like to propose that we try to cut a 4.1 release before the summer break, roughly a year after 4.0
I think it’s both a reasonable goal and a good time for an important release. I anticipate no one will have time for coordinated work during summer, and the fall is traditionally not ideal either: many of us are on teaching duty, and it’s also when the Python ecosystem is least stable.
There are a couple blockers that need to be adressed to get the dev branch back to a release-ready state, namely
1) in 4.0 we promised (in the form of deprecation warnings) that in 4.1, errors would be raised from ambiguous name-only field keys. Actually implementing this poses a couple difficulties (see https://github.com/yt-project/yt/issues/3381 and https://github.com/yt-project/yt/issues/3839) but nothing insurmountable.
2) We need to reach a consensus on how the new axis flipping/swapping machinery should behave. There’s an open discussion for this here https://github.com/yt-project/yt/issues/3890
To get a broader (possibly more confusing) view of the TODO list, see the open milestone: https://github.com/yt-project/yt/milestone/17
I’ve highlighted what I think are the most crucial points with the “release critical” label.
You can help by discussing and triaging open issues and PRs to and from the milestone.
It’s also a good time to get feature PRs to the finish line.
We haven’t made any big “promises” for yt 4.2 (or nothing as significant as the ambiguous field stuff), so I’m hopeful that getting 4.1 out the door will allow us to make more frequent feature releases in the foreseeable future.
Any feedback is most welcome
Best
Clément
Hi team,
I’d like to raise awareness on a small but recuring issue we’ve been having with how CI interacts with Github auto-merge.
As a reminder, auto-merge is a GH feature with allows us to set a PR to be merged automatically after configurable requirements are met.
The issue with our current configuration is that the “answer test” job is required, but does not always turn. In particular it doesn’t run on docs-only PRs.
This creates a situation where the PR is stuck on a “wait” status, and only repo owners can merge.
The latest example is https://github.com/yt-project/yt/pull/3963
I can see two solutions:
- update the requirements to exclude this particular job (or make it conditional ? I’m not sure that’s supported)
- change the rules and run normal CI even on docs-only PRs
Is there a preference ?
Clément
