You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That issue has stalled because the solutions to it tend to involve inserting themselves into the day-to-day development workflow — after all, they need to control what version of Flutter gets used — and none of the known solutions have felt totally satisfactory to me. Also because, in practice, our existing workflow without actual pinning generally works just fine.
There is one aspect that's bugged me a few times so far in practice, though, and which doesn't call for changing anything in the day-to-day workflow so it should be much easier to resolve: I'd like to know the Git commit ID for the Flutter version that we were using at a specific point in the repo's history. Specifically in practice, I want to know what Flutter commit ID was used for a given published (beta) release.
I already make a practice of building each release with the exact minimum version recorded in pubspec.yaml, in order to make it reproducible. So this information is there in principle, encoded in that version number. But from those Flutter version numbers (3.27.0-1.0.pre.518, in our pubspec.yaml in main at the moment) it's somewhat annoying to identify the actual Git commit ID (01590aa27ac4d3a904d25ae4c6b792f933a3da6f in that example, i.e. flutter/flutter@01590aa).
We can solve this by just having the commit ID also in pubspec.yaml, e.g. in a comment on the same line. Then tools/upgrade can maintain the comment. Ideally, we can even have a check in tools/check that verifies it's accurate.
The text was updated successfully, but these errors were encountered:
Fixeszulip#1118, or anyway the main part of it.
Upcoming commits will add a suite in tools/check that validates
this information, in case this line gets updated manually rather
than using this script.
Fixeszulip#1118, or anyway the main part of it.
Upcoming commits will add a suite in tools/check that validates
this information, in case this line gets updated manually rather
than using this script.
This issue can be seen as a much-scoped-down version of pinning the Flutter version:
That issue has stalled because the solutions to it tend to involve inserting themselves into the day-to-day development workflow — after all, they need to control what version of Flutter gets used — and none of the known solutions have felt totally satisfactory to me. Also because, in practice, our existing workflow without actual pinning generally works just fine.
There is one aspect that's bugged me a few times so far in practice, though, and which doesn't call for changing anything in the day-to-day workflow so it should be much easier to resolve: I'd like to know the Git commit ID for the Flutter version that we were using at a specific point in the repo's history. Specifically in practice, I want to know what Flutter commit ID was used for a given published (beta) release.
I already make a practice of building each release with the exact minimum version recorded in pubspec.yaml, in order to make it reproducible. So this information is there in principle, encoded in that version number. But from those Flutter version numbers (
3.27.0-1.0.pre.518
, in ourpubspec.yaml
in main at the moment) it's somewhat annoying to identify the actual Git commit ID (01590aa27ac4d3a904d25ae4c6b792f933a3da6f
in that example, i.e. flutter/flutter@01590aa).We can solve this by just having the commit ID also in pubspec.yaml, e.g. in a comment on the same line. Then
tools/upgrade
can maintain the comment. Ideally, we can even have a check intools/check
that verifies it's accurate.The text was updated successfully, but these errors were encountered: