Determine new release process for high traffic packages in flutter/packages

[Piinks]

This issue tracks the work to design and implement a new batch release process for high-traffic packages in the flutter/packages repository.

For high-traffic packages, requiring every pull request to manually update CHANGELOG.md and pubspec.yaml creates a constant stream of merge conflicts. This slows down contributions and increases the maintenance burden.

The objective is to create a process that eliminates these merge conflicts by batching version and changelog updates. This will likely involve a rolling cron job in cocoon where changelog entries are generated automatically from pull request titles, labels, or specific sections in the PR body.

Motivated by

• ☂️ Move the material and cupertino packages outside of Flutter #101479

We should implement this using go_router and go_router_builder as canaries, since they regularly experience this pain point.

[chunhtai]

something we can look into https://stackoverflow.com/questions/70292203/is-it-possible-to-update-files-as-part-of-a-merge-via-github-actions-without-cre

we can try to write changelog and version bump after the merge initiate and before the change is actually pushed to the main

[stuartmorgan-g]

A commit that changes the version triggers the autorelease system. A system that creates unreviewed/unreviewable changes that trigger release would be extremely dangerous, and as such would require extensive design and engineering work to ensure that it was robust enough and foolproof enough that it could not cause mistakes—for example, using a non-major version for a breaking change—that would be auto-published to every single package client.

I would advise very strongly against trying to create a system that remove all human safeties from the most user-critical part of the pipeline.

Also, my understanding is that an explicit part of the goal for this is to not use the continuous release model, and instead control when releases happen. In that context, it's not clear what problem a post-submit hook would solve, as there is no potential for conflicts at that point.

[chunhtai]

I am still brainstorming ideas.

I was thinking about using some kind of labels for various kind of version bump

for example adding these label

label: major
label: minor
label: patch

and the existing
label: no versioning needed

every pr will need exact one of these kind of labels to be able to merge, and the merge hook will based on this to bump pubspec.yaml.

it will also take commit message, ie PR title as the new change log entry

It will be the reviewer to make sure the label is added appropriately as well as pr title.

Also, my understanding is that an explicit part of the goal for this is to not use the continuous release model, and instead control when releases happen

in this system people can still hold the release by using label: no versioning needed for consecutive pr until a release can be cut. The label name should probably change to label: skip release if there is indeed such use case though

[stuartmorgan-g]

I would really recommend starting with a high-level document describing what the desired release process should be, ignoring the technical implementation, getting consensus on that, and then looking at potential implementations. Without knowing what the core use cases are, it's going to be impossible to design a technical solution that can implement those solutions.

As an example: is human-controlled batching a requirement, or not, and if so, it is going to be done via branching, or via controlled releases of what is on main? If the answer is that human-controlled batching via controlled release of main is the desired outcome, then the technical system you are describing isn't viable, because individual PR authors can no longer predict what the correct release semantics are within the context of their own PR.

[stuartmorgan-g]

As an example of what I mean by use cases, consider the following scenario:

• Person A wants to make a breaking change.
• Person B wants to make a breaking change.
• People C-G wants to make unrelated minor bug fixes.
• The package owners wants to batch the breaking changes of Person A and Person B into one major version change.
• People C-G are unaware of any of this.

What is the desired outcome, at a high level? Is it for A and B to coordinate the landing of their PRs? Is it for A and B to be able to land independently of each other, and if so, is it okay if the bug fixes from C-G cannot be published after one of A and B land but before both land? (And if the latter, what if one of those is a time-critical fix?) Is it for A and B to be able to land independently without impacting the ability to publish C-G (in which case A and B probably need to use a branch; is someone willing to take on branch management)?