Revert "document default flavor" because the feature is not yet available on stable #10646
Conversation
This reverts commit 4e72d2a.
|
Visit the preview URL for this PR (updated for commit 59d7a0d): https://flutter-docs-prod--pr10646-revert-10642-fix-document-d-jb5rmmld.web.app |
|
Your proposed standard is mostly what we informally follow, but we should likely standardize and document it. Informally, what we have done is leave the PR in draft mode, and added a "[3.22]" or "[Next release]" prefix to the header, similar to what you've mentioned. Then leaving a comment indicating the requirements for when it should land. Tooling is also an option if a good standard can be determined. I'll leave the decision and documentation of that to Shams and Tony and land this for now, but please do continue to proactively open PRs for features that aren't stable or even landed yet. We'll make sure they don't get forgotten and it's extremely appreciated. Thanks! I'll add as a note that I'm personally all for documenting features that are in beta releases as long as the text clearly indicates the release status of the feature. |
Reverts #10642.
This is a similar story to #10641. TL;DR a contributor merged a new feature into the master branch of flutter/flutter and also kindly drafted a website change to document this feature. However, this change shouldn't have been merged until the feature is actually available on the stable channel.
Question for @sfshaza2 and/or other maintainers: I've had this happen to myself, and I'd like to make it easy for folks to not accidentally merge these PRs too early. In these types of situations where we have some change to flutter/flutter and want to proactively prepare website updates for them, what would you prefer? Here is an idea to start with: we continue to draft these PRs early, but maybe with sort of hard-to-miss message saying not to merge until next stable release. For example, the PR title could start with "[DON'T MERGE]" or "[NEXT STABLE]", and the first line of the description could read "Do not merge until the next stable release after 3.22., which is when
<link to Flutter PR>will be available.".I imagine this type of situation isn't frequent/dire enough to warrant any technical investment, but—just as an idea—I think it would be really cool if we had some sort of automated mechanism for this (perhaps using GitHub labels and bots).