8000 Streamlining Bug Fix Releases · Issue #25564 · scikit-learn/scikit-learn · GitHub
[go: up one dir, main page]
Skip to content

Streamlining Bug Fix Releases #25564

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
thomasjpfan opened this issue Feb 7, 2023 · 5 comments
Open

Streamlining Bug Fix Releases #25564

thomasjpfan opened this issue Feb 7, 2023 · 5 comments
Labels
workflow Development workflow changes

Comments

@thomasjpfan
Copy link
Member

Reading over #25457 I wish we had workflow where we can immediately backport fixes to 1.2.X once the fix is on main. This way we do not need to do a big interactive rebase when we release. We would only need to update the authors list and then cut a release directly from 1.2.X.

I think the only thing stopping us from directly back-porting fixes to upstream/1.2.X is that it updates the documentation right away. In that case, I see two ways around this:

  1. A new doc/1.2.X branch that gets deployed to the docs. doc/1.2.X will always be behind 1.2.X. When we release, sync doc/1.2.X up with 1.2.X.
  2. A new dev/1.2.X that we backport fixes to. dev/1.2.X will always be ahead of 1.2.X. When we release, sync 1.2.X up with dev/1.2.X.

I know this adds a little more process, but I think making it easier to cut bug fix releases.
@thomasjpfan thomasjpfan added the workflow Development workflow changes label Feb 7, 2023
@betatim
Copy link
Member
betatim commented Feb 8, 2023

Option (2) sounds like it would require less (new) infrastructure changes.

A side comment related to backporting: https://meeseeksbox.github.io/ (https://github.com/MeeseeksBox) is used by a few projects that do backports and quite popular. It removes the need to manual backporting and can even act based on merged PR labels.

ps. the title has a typo, should be "Streamlining"

@thomasjpfan thomasjpfan changed the title Streamling Bug Fix Releases Streamlining Bug Fix Releases Feb 8, 2023
@glemaitre
Copy link
Member

For meeseeksbox, it would require a more significant shift on how we are branching if I recall correctly (not that I am against it). My only concern is about the difficulty of automatically backporting with the way that we currently handle our changelog. We usually get some conflict there which could be problematic with automatic backport but I am not sure. I think that we should be investigating this part.

Regarding the process, we just move some burden that is currently on the release manager to all maintainers (again I am not against it :)). Then, we would need a more systematic way of knowing exactly what goes into the bugfix release as well.

@thomasjpfan
Copy link
Member Author

As for having a bot to do auto backports, there are many GitHub actions to choose from that trigger on labels.

As for conflicts on the changelog, I think we can do those manually, right after the PR is merged into main. Historically, we typically have around 15 new changelog items for bug fix releases, which feels manageable. Many of the other backported commits are documentation changes that can more easily be automated.

Overall, I want to make it easier for the release manager. 😅

@betatim
Copy link
Member
betatim commented Feb 9, 2023

As for having a bot to do auto backports, there are many GitHub actions to choose from that trigger on labels.

The reason I brought up meseeks specifically is that it is used by other scientific python projects for a while and the developer(s) are from the community. This increases the chances that it fits how projects work (and lower chance of getting compromised?), changes can be made, etc compared to picking a random tool from the GH marketplace.

We could find out how ipython and scikit-image do their changelog to learn about dealing with conflicts.

Spreading the load sounds like a good idea. Anything to make "making a release" less of an event and more of a routine "nothing to see here" task.

@thomasjpfan
Copy link
Member Author
thomasjpfan commented Feb 9, 2023 •
edited
Loading

I have seen meeseeksbox work well for other libraries. For me, it adds a dependency on another external Heroku service. For a GitHub Action workflow, we can limit the permissions to only allow it to create a PR. (No write permissions to the branches, etc.) In any case, I am okay with any solution we choose.

We could find out how ipython and scikit-image do their changelog to learn about dealing with conflicts.

Many other open source projects have a folder of change log files, one file per PR. During release time, they run a script to merge the files together. For example, matplotlib has a next_whats_new folder for upcoming changes and a prev_whats_new folder with the combined change logs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
workflow Development workflow changes
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@betatim @thomasjpfan @glemaitre
0