[tool] Support pre-1.0 versions in batch releases by stuartmorgan-g · Pull Request #12257 · flutter/packages

stuartmorgan-g · 2026-07-21T16:24:35Z

Adds support for Dart's semver convention of shifting the conceptual meaning of versions by one place for pre-1.0 package when determining batch release versions.

For example, a batch release with a "major" changelog entry would go from 0.x.y to 0.x+1.0.

Adds support for Dart's semver convention of shifting the conceptual meaning of versions by one place for pre-1.0 package when determining batch release versions. For example, a batch release with a "major" changelog entry would go from 0.x.y to 0.x+1.0.

gemini-code-assist

Code Review

This pull request adds support for batch releasing pre-1.0 packages by removing the version restriction and implementing Dart semantic versioning rules for pre-1.0 version bumps. Corresponding unit tests have been added and updated. Feedback on the changes includes correcting a typo in the changelog and addressing an unsafe cast to int on the first build identifier of oldVersion.build, which could throw a runtime TypeError if the identifier is a string.

gemini-code-assist · 2026-07-21T16:25:39Z


+  Version? _newVersionFollowingDartSemVer(Version oldVersion, VersionChange change) {
+    if (oldVersion.major == 0) {
+      final oldBuildNumber = oldVersion.build.isEmpty ? 0 : oldVersion.build.first as int;


Casting oldVersion.build.first as int is unsafe because build metadata identifiers in pub_semver can be either integers or strings (e.g., 0.1.0+alpha or 0.1.0+1.2). If the first build identifier is a string, this cast will throw a runtime TypeError.

It is safer to check the type and parse it if necessary.

final Object? firstBuild = oldVersion.build.isEmpty ? null : oldVersion.build.first; final int oldBuildNumber = firstBuild is int ? firstBuild : (int.tryParse(firstBuild?.toString() ?? '') ?? 0);

We don't usually do x.y.z+a.b releases in flutter/packages, correct? So maybe this is a non-issue?

Right, we only do +N.

justinmc · 2026-07-21T16:29:51Z

+      return switch (change) {
+        VersionChange.skip => null,
+        VersionChange.major => Version(0, oldVersion.minor + 1, 0),
+        VersionChange.minor => Version(0, oldVersion.minor, oldVersion.patch + 1),
+        VersionChange.patch => Version(
+          0,
+          oldVersion.minor,
+          oldVersion.patch,
+          build: '${oldBuildNumber + 1}',
+        ),
+      };


I didn't realize this affects the version bump differently from a post-v1 release. I made my release a patch release assuming that would bump it to 0.0.2:

packages/packages/cupertino_ui/pending_changelogs/change_2026_07_20_12251.yaml

Line 7 in 796e5b1

version: patch

Should I land a quick PR that changes that to minor?

Also, does this mean that we can't release 1.0.0 via the batch release process, we'll have to do it manually?

Also, does this mean that we can't release 1.0.0 via the batch release process, we'll have to do it manually?

Ugh, I hadn't considered that. I was just thinking of this the same way the update-release-info command works, but for that we just don't handle 0.x->1.0 because it can trivially be done manually.

Maybe the bettor option here is just to turn off batch releasing for now, and do continuous releases with publish_to:none between releases, until you are ready for 1.0?

Or we could land this, and then figure out how to special case the 1.0 release sometime before you want to do the 1.0 release. Which would you prefer?

Hmm, maybe to uncomplicate the 1.0, we should just not use batch release for this and use the regular release process through CI for this one? @justinmc WDYT?

Sounds good either way, but given the current code:

packages/script/tool/lib/src/branches_for_batch_release_command.dart

Lines 81 to 86 in 796e5b1

if (pubspec.version == null || pubspec.version!.major < 1) {

printError(

'This script only supports packages with version >= 1.0.0. Current version: ${pubspec.version}.',

);

throw ToolExit(_kExitPackageMalformed);

}

Regardless of whether or not we land this PR, we won't be able to use the batch release process for 1.0.0, right? So if I'm understanding correctly, I say we should land this PR and use the batch release process (triggered manually) to publish the prerelease. Then we'll have to figure something out for 1.0.0 either way.

Then we'll have to figure something out for 1.0.0 either way.

Well, I was thinking that if you went off of batched releases you would stay off of them until you'd done the 1.0 release. But I'll land this and then think about how we could do 1.0 without having to change process. Maybe just a new special change type keyword.

Sounds good, thanks for looking into it. A new keyword would work for me.

By landing this PR as-is, at least we'll get some verification that the batch release process works before we need everyone to follow it post-1.0.0.

Piinks

I concur with G on the typo. Otherwise LGTM. Thank you!

Piinks · 2026-07-21T16:30:41Z


+  Version? _newVersionFollowingDartSemVer(Version oldVersion, VersionChange change) {
+    if (oldVersion.major == 0) {
+      final oldBuildNumber = oldVersion.build.isEmpty ? 0 : oldVersion.build.first as int;


We don't usually do x.y.z+a.b releases in flutter/packages, correct? So maybe this is a non-issue?

justinmc

LGTM but see my comment https://github.com/flutter/packages/pull/12257/changes#r3623894822.

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

See #12257 (comment). This PR shouldn't land unless that one does.

Gets material_ui ready for 0.0.2 to be published. Follows the same pattern as cupertino_ui in #12251. Unlike that PR, I set the change to `minor` instead of `patch`. See #12257 (comment). Plus, changes the dependency on cupertino_ui to reference the published 0.0.2 prerelease. That isn't published yet, so this commit should fail CI until it is published. ~~Depends on #12253

stuartmorgan-g requested review from Piinks and justinmc July 21, 2026 16:24

flutter-dashboard Bot added the CICD Run CI/CD label Jul 21, 2026

gemini-code-assist Bot reviewed Jul 21, 2026

View reviewed changes

justinmc reviewed Jul 21, 2026

View reviewed changes

Piinks approved these changes Jul 21, 2026

View reviewed changes

justinmc approved these changes Jul 21, 2026

View reviewed changes

justinmc mentioned this pull request Jul 21, 2026

[material_ui] Prerelease setup #12258

Merged

Fix changelog typo

6513c2e

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

justinmc mentioned this pull request Jul 21, 2026

[cupertino_ui] Bump minor to get to 0.0.2, not patch #12260

Merged

stuartmorgan-g added the autosubmit Merge PR when tree becomes green via auto submit App label Jul 21, 2026

auto-submit Bot merged commit 1519e2f into flutter:main Jul 21, 2026
13 checks passed

auto-submit Bot pushed a commit that referenced this pull request Jul 21, 2026

[cupertino_ui] Bump minor to get to 0.0.2, not patch (#12260)

161d1f4

See #12257 (comment). This PR shouldn't land unless that one does.

stuartmorgan-g deleted the tool-batch-pre-one-point-oh branch July 21, 2026 18:00

	if (pubspec.version == null \|\| pubspec.version!.major < 1) {
	printError(
	'This script only supports packages with version >= 1.0.0. Current version: ${pubspec.version}.',
	);
	throw ToolExit(_kExitPackageMalformed);
	}

Uh oh!

Conversation

stuartmorgan-g commented Jul 21, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

gemini-code-assist Bot Jul 21, 2026

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!

Piinks left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

justinmc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants