Release automation. by polina-c · Pull Request #917 · flutter/genui

polina-c · 2026-05-13T19:08:42Z

Prerequisite: #926

Add workflows to automate release process (off for now)
Document release process
Cleanup some documentation
Fix pub.dev warnings by removing checked-in git ignores
Fix release validation errors
Document update story (with dependabot)
Remove release tool, because it is not needed any more
Update .github/dependabot.yaml to check packages that are not in root '/' -> '/**'
Pin analyser and comment the problem
Add CI validation for locally broken version constraints

polina-c · 2026-05-16T21:20:31Z

/gemini review

gemini-code-assist

Code Review

This pull request restructures the project's contribution documentation by moving detailed guidelines from the root CONTRIBUTING.md to a new docs/contributing directory, which now includes dedicated guides for publishing and pull requests. It also updates package versions and adds publishing restrictions to internal tools. The review feedback identified several opportunities to improve the clarity, grammar, and link stability of the newly added documentation files.

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

gspencergoog · 2026-05-18T19:38:10Z

+2. **Not yet published**: the package's `version:` ends with a `-dev<N>` suffix (see "`-dev` vs non-`-dev`" below). Published to pub.dev only to reserve the name; not ready for general use yet.
+3. **Published**: any other package. Each has its own version cadence on pub.dev.
+
+Note: `resolution: workspace` in a `pubspec.yaml` is a tooling concern — it tells Dart to share dependency resolution and a lockfile with the monorepo, and it does **not** by itself imply anything about release cadence. A package can opt out of the workspace (omit `resolution: workspace`) to avoid circular dependencies or unrelated update churn while still being a published package.


If a package opts out of the monorepo, however, it is then implicitly switching to using published packages only, and local changes won't be testable without manual editing of the pubspec files to use local paths, or publishing the dependent packages.

How does using the monorepo increase circular dependency problems? It seems like it would make them better, not worse, since you're using the local versions of the code. But maybe I don't understand the use case you're describing.

And what kind of "update churn"? Since it doesn't imply anything about release cadence, I wouldn't think that would increase the churn. Are you referring to churn in publishing other packages, or churn the package that is part of the monorepo?

Thank you!

Yes this documentation was confusing and some sentences are wrong. Updated.

We still use advantages of monorepo. Added section to explain how.

gspencergoog · 2026-05-18T19:45:27Z

+
+   1.2. The package's changes touch only non-publishable code or docs (like tests, tools, or not-publishable docs).
+
+   You can publish `-dev<number>` versions, if you need it for development. 


What is the format of <number>? Is it another semver number, or just an ordinal? Is it zero padded, or does it have a dash?

e.g. which of these is it?:

0.1.0-dev1

0.1.0-dev001

0.1.0-dev-1

`0.1.0-dev-0.1.0'

Thank you. Updated doc.

I don't see a description of the format of <number> in the -dev<number> suffix.

gspencergoog · 2026-05-18T19:46:27Z

+
+   You can publish `-dev<number>` versions, if you need it for development. 
+
+2. If your feature is partially implemented, hide the feature's code behind a false-by-default flag, and use **release-ready** version.


Where are the flags specified? Are they --define flags for the Dart compiler? Or are they command line flags? Something else?

We do not have it organized yet. Documented that it is not defined yet.

gspencergoog · 2026-05-18T19:47:22Z

+
+For packages with `resolution: workspace` in their pubspec.yaml, pub resolves every sibling from its local source directory — not from pub.dev, as long as its `version:` satisfies the consumer's constraint.
+
+If a local bump escapes that constraint (e.g. `^0.9.0` → `0.10.0`), update the consumer's `pubspec.yaml` in the same PR. Otherwise pub silently falls back to the published version on pub.dev.


Can we have a check for this?

Good idea!

added

gspencergoog · 2026-05-18T19:48:14Z

+
+After a new version of a dependency (including sibling package in this repo) is published, this is how upgrade will happen:
+
+1. [Dependabot] detects the new version on pub.dev and opens a PR per dependency, bumping the constraint in each consuming `pubspec.yaml`. See [About Dependabot version updates] for details.


Is there any way to add a new section to each CHANGELOG.md too?

Not natively — Dependabot only edits the manifest. I filed a feature request upstream: dependabot/dependabot-core#15057. For now the doc calls out that the CHANGELOG.md entry has to be added by the maintainer before merging.

Filed an issue and added comment: dependabot/dependabot-core#15057

gspencergoog · 2026-05-18T19:51:00Z

+## Shell scripts

-Do not review pull requests when they are in draft state, unless explicitly requested by the author.
+To run a script in `tool/`, open the script in VSCode and press ⇧⌘B.


Also add instructions for where to run the script from on the command line: not everyone uses VSCode, and that key binding is Mac-only, so you might include the default Linux keybinding too (which is likely to be the same as Windows). They also might have changed the keybinding...

gspencergoog · 2026-05-18T19:58:37Z


-## 0.2.4 (in progress)
-
- **Refactor**: Update core framework to v0.9 (#546dab9be).


This comment is now lost. When will it be added back in? Shouldn't there be a section for in progress (-dev) changes?

Changed the comment to make sense in the context of the package genai_primitives, that is not concerned about genui.

Bumped version

But what about in-progress changes: Say I've committed something that isn't meant to be published yet, but I want to accumulate CHANGELOG entries for it when it is published. How am I supposed to do that? I would think there would be a ## 0.2.4-dev entry here with those things, that gets converted to a ## 0.2.4 heading before it is published.

Yes, you are right.

And this change is samll enough to hold for next release.

Changed.

gspencergoog · 2026-05-18T19:59:22Z

 name: fix_copyright
 description: A command line app to fix copyright headers.
+publish_to: none
 version: 0.1.0


If this is publish: none, should it also have a -dev version number?

it should not have version number at all

deleted here and in other places

gspencergoog · 2026-05-18T20:00:41Z

@@ -1 +0,0 @@
-submodules/JSON-Schema-Test-Suite/**


If you remove this, then the test suite will be re-published with the package, and that's not our code. It will also make the package a lot bigger, and it's not data that we need to publish.

Don't we need to keep this?

reverted

thank you!

Co-authored-by: Greg Spencer <gspencergoog@users.noreply.github.com>

gspencergoog · 2026-05-18T22:53:11Z

+
+## About `resolution: workspace`
+
+`resolution: workspace` in a `pubspec.yaml` is a tooling concern and it does **not** by itself imply anything about release cadence:


Why is it a "concern"? That implies that we don't really want to use it. Or do you mean that it only is something for the tooling to worry about?

good catch

resolved

gspencergoog · 2026-05-18T22:59:25Z

+
+   1.2. The package's changes touch only non-publishable code or docs (like tests, tools, or not-publishable docs).
+
+   You can publish `-dev<number>` versions, if you need it for development. 


I don't see a description of the format of <number> in the -dev<number> suffix.

polina-c · 2026-05-18T23:10:33Z

I don't see a description of the format of in the -dev suffix.

Yes, user expects to see it here. Moved here from above.

Co-authored-by: Greg Spencer <gspencergoog@users.noreply.github.com>

polina-c added 3 commits May 13, 2026 12:07

Create publish.yaml

525db20

Merge branch 'main' of https://github.com/flutter/genui into publish

15412d8

-

6b53a7b

polina-c marked this pull request as draft May 14, 2026 21:26

polina-c added 14 commits May 15, 2026 11:21

Update publish.yaml

a726a97

Merge branch 'main' of https://github.com/flutter/genui into publish

a103178

-

03af6a8

-

052e2c4

Update CONTRIBUTING.md

9425693

-

6554fc1

Update pull_requests.md

1afbe08

-

0f7cfa5

Merge remote-tracking branch 'refs/remotes/origin/publish' into publish

34611bd

Update publishing.md

bca0e66

Update publishing.md

0a6181a

-

40c9e68

Update publishing.md

2f072a4

-

56d618f

gemini-code-assist Bot reviewed May 16, 2026

View reviewed changes

polina-c and others added 10 commits May 16, 2026 14:26

-

9939064

-

751f970

Update docs/contributing/pull_requests.md

33359ad

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Update docs/contributing/publishing.md

c5cb8b1

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Update docs/contributing/publishing.md

667bad4

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Update docs/contributing/publishing.md

7d81961

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Update docs/contributing/publishing.md

61c45a3

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

Update docs/contributing/publishing.md

656824b

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>

-

36a982f

Merge remote-tracking branch 'refs/remotes/origin/publish' into publish

2048223

polina-c added 2 commits May 17, 2026 11:29

-

a1244d8

Merge branch 'main' of https://github.com/flutter/genui into publish

f196a2d

polina-c marked this pull request as ready for review May 18, 2026 19:25

gspencergoog reviewed May 18, 2026

View reviewed changes

polina-c added 6 commits May 18, 2026 13:10

fix notes about monorepo

6c67d4c

Update publishing.md

bf5bbcc

Update publishing.md

d935eaf

add check for internal workspace version constraints

b6108a8

-

c12ca9c

-

beb63c7

polina-c mentioned this pull request May 18, 2026

Feature request: append an entry to CHANGELOG.md when bumping a dependency dependabot/dependabot-core#15057

Open

polina-c and others added 6 commits May 18, 2026 15:32

Update docs/contributing/README.md

191d3fd

Co-authored-by: Greg Spencer <gspencergoog@users.noreply.github.com>

-

864411a

Merge remote-tracking branch 'refs/remotes/origin/publish' into publish

edffbb7

Update workspace_verifier.dart

fe0afbf

-

74b83e6

-

dec4e00

polina-c requested a review from gspencergoog May 18, 2026 23:00

gspencergoog reviewed May 18, 2026

View reviewed changes

polina-c added 2 commits May 18, 2026 16:08

Update publishing.md

bf5d6fd

Update publishing.md

c4bd84a

-

61d1252

polina-c requested a review from gspencergoog May 18, 2026 23:15

gspencergoog approved these changes May 18, 2026

View reviewed changes

Comment thread docs/contributing/README.md Outdated

Comment thread docs/contributing/publishing.md Outdated

polina-c and others added 3 commits May 18, 2026 16:42

-

957f7e3

Update README.md

ffa9f6a

Update docs/contributing/publishing.md

0f189cf

Co-authored-by: Greg Spencer <gspencergoog@users.noreply.github.com>

polina-c merged commit 56d7932 into flutter:main May 18, 2026
23 checks passed

polina-c deleted the publish branch May 18, 2026 23:49


		1.2. The package's changes touch only non-publishable code or docs (like tests, tools, or not-publishable docs).

		You can publish `-dev<number>` versions, if you need it for development.


		You can publish `-dev<number>` versions, if you need it for development.

		2. If your feature is partially implemented, hide the feature's code behind a false-by-default flag, and use release-ready version.


		For packages with `resolution: workspace` in their pubspec.yaml, pub resolves every sibling from its local source directory — not from pub.dev, as long as its `version:` satisfies the consumer's constraint.

		If a local bump escapes that constraint (e.g. `^0.9.0` → `0.10.0`), update the consumer's `pubspec.yaml` in the same PR. Otherwise pub silently falls back to the published version on pub.dev.


		After a new version of a dependency (including sibling package in this repo) is published, this is how upgrade will happen:

		1. [Dependabot] detects the new version on pub.dev and opens a PR per dependency, bumping the constraint in each consuming `pubspec.yaml`. See [About Dependabot version updates] for details.


		## 0.2.4 (in progress)

		- Refactor: Update core framework to v0.9 (#546dab9be).


		## About `resolution: workspace`

		`resolution: workspace` in a `pubspec.yaml` is a tooling concern and it does not by itself imply anything about release cadence:

		@@ -1 +0,0 @@
		submodules/JSON-Schema-Test-Suite/**

Conversation

polina-c commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

polina-c commented May 16, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gspencergoog May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gspencergoog May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

polina-c commented May 18, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

polina-c commented May 13, 2026 •

edited

Loading

gspencergoog May 18, 2026 •

edited

Loading

gspencergoog May 18, 2026 •

edited

Loading