Update grinder script. #1627
Merged
Update grinder script. #1627
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The workflow for shipping dart_style used to be that we published a new version on pub and then rolled it into the Dart SDK. That meant that the dart_style version number in the SDK accurately described what was in dart_style. A few years ago, we changed to rolling into the SDK first. That lets us validate dart_style inside google3 before irrevocably publishing, which is a good thing. But it has an unfortunate side effect. If you run `dart format --version`, it shows the *previous* version number of dart_style because the version number only gets bumped when we publish. This is really confusing if you're trying to debug the formatter in the SDK and it appears to be an older version than it actually is. To fix that, I'm tweaking the workflow slightly. When we begin working on a new version of the formatter, we bump the version number in the pubspec to, say, 3.4.5-wip. At that point, we immediately update the version number constant shown by `--version` to "3.4.5" (the version it *will* be). That way, when it gets rolled into the SDK, it prints the upcoming version number. When a version of dart_style is about to be published, we remove `-wip` from the pubspec but the constant printed by `--version` is already done. To make this workflow a little less error-prone, I updated the grinder script to add tasks for starting a new patch, minor, and major version. I also updated the docs for the old task now that we use the workflow automation for publishing.
kevmoo
approved these changes
Dec 17, 2024
Co-authored-by: Kevin Moore <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The workflow for shipping dart_style used to be that we published a new version on pub and then rolled it into the Dart SDK. That meant that the dart_style version number in the SDK accurately described what was in dart_style.
A few years ago, we changed to rolling into the SDK first. That lets us validate dart_style inside google3 before irrevocably publishing, which is a good thing. But it has an unfortunate side effect. If you run
dart format --version, it shows the previous version number of dart_style because the version number only gets bumped when we publish. This is really confusing if you're trying to debug the formatter in the SDK and it appears to be an older version than it actually is.To fix that, I'm tweaking the workflow slightly. When we begin working on a new version of the formatter, we bump the version number in the pubspec to, say, 3.4.5-wip. At that point, we immediately update the version number constant shown by
--versionto "3.4.5" (the version it will be). That way, when it gets rolled into the SDK, it prints the upcoming version number.When a version of dart_style is about to be published, we remove
-wipfrom the pubspec but the constant printed by--versionis already done.To make this workflow a little less error-prone, I updated the grinder script to add tasks for starting a new patch, minor, and major version.
I also updated the docs for the old task now that we use the workflow automation for publishing.