Update android releases page with more details around each release type #2648
Conversation
📝 WalkthroughWalkthroughThe Android release documentation was expanded to clarify the internal testing and beta release process. It specifies that every approved and merged PR is immediately pushed to the internal beta channel on the Play Store for real-world testing, especially for Android Auto/Automotive, since debug builds do not appear in vehicles. The weekly beta release timing was clarified as every Saturday at 9pm PST, with instructions to update the beta change log on Friday or Saturday. The production release section was detailed with explicit steps including updating change logs, unchecking the pre-release checkbox on GitHub, merging companion documentation PRs to remove beta labels, and notifying relevant teams. No changes were made to workflows or validations. Changes
Sequence Diagram(s)No sequence diagram is necessary, as the change is limited to documentation updates without affecting control flow or features. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
docs/android/release.md (1)
46-46: Clear reminder to remove beta labels from docs.The added sentence explicitly instructs maintainers to update companion documentation by removing any beta labels once the production release is approved, enhancing clarity in the Android release process. Consider applying a similar note in other platform release guides (e.g., iOS) for consistency across documentation.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/android/release.md(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Redirect rules - developers-home-assistant
- GitHub Check: Header rules - developers-home-assistant
- GitHub Check: Pages changed - developers-home-assistant
jpelgrom
changed the title
dshokouhi
changed the title
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
docs/android/release.md (5)
33-33: Clarify and fix hyphenation for “real-world testing.”Use a hyphen in “real-world” and add a comma before the subordinate clause for clarity and consistency:
- Every approved and merged PR is pushed to the internal beta channel on Play Store for immediate feedback. This is the only way to do real world testing for Android Auto/Automotive as the debug builds will not show up in an actual vehicle. + Every approved and merged PR is pushed to the internal beta channel on Google Play Store for immediate feedback. This is the only way to do real‑world testing for Android Auto/Automotive, as the debug builds will not show up in an actual vehicle.🧰 Tools
🪛 LanguageTool
[uncategorized] ~33-~33: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...te feedback. This is the only way to do real world testing for Android Auto/Automotive as ...(EN_COMPOUND_ADJECTIVE_INTERNAL)
[uncategorized] ~33-~33: Possible missing comma found.
Context: ... do real world testing for Android Auto/Automotive as the debug builds will not show up in...(AI_HYDRA_LEO_MISSING_COMMA)
38-39: Streamline phrasing in the weekly beta release steps.Consider replacing “prior to” with “before” and consolidating the timing information for brevity:
- Every week at 9pm PST on Saturday, the latest version of the `main` branch is pushed to the **open beta** channel. - On Friday or Saturday prior to the beta cut off above, update the beta change log highlighting new features and breaking changes (if applicable) + Every Saturday at 9pm PST, the latest `main` build is pushed to the **open beta** channel. + Before that cutoff (Friday or Saturday), update the beta changelog to highlight new features and breaking changes.🧰 Tools
🪛 LanguageTool
[style] ~39-~39: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...beta** channel. - On Friday or Saturday prior to the beta cut off above, update the beta...(EN_WORDINESS_PREMIUM_PRIOR_TO)
50-50: Consider one-word “changelog” for consistency.Many docs use “changelog” as a single word; adopting that convention throughout may improve uniformity.
51-51: Correct GitHub casing.The official product name is “GitHub,” not “Github.”
- Uncheck the pre-release checkbox in Github for the latest beta + Uncheck the pre-release checkbox in GitHub for the latest beta
53-53: Capitalize “Discord” for proper noun consistency.Use the correct casing for the platform name:
- Notify Community Manager and Android discord channel about the upcoming release and highlights for social media + Notify Community Manager and Android Discord channel about the upcoming release and highlights for social media
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/android/release.md(2 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/android/release.md
[uncategorized] ~33-~33: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...te feedback. This is the only way to do real world testing for Android Auto/Automotive as ...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[uncategorized] ~33-~33: Possible missing comma found.
Context: ... do real world testing for Android Auto/Automotive as the debug builds will not show up in...
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~39-~39: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...beta** channel. - On Friday or Saturday prior to the beta cut off above, update the beta...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Redirect rules - developers-home-assistant
- GitHub Check: Header rules - developers-home-assistant
- GitHub Check: Pages changed - developers-home-assistant
🔇 Additional comments (2)
docs/android/release.md (2)
48-48: Production release section added correctly.The new header and introductory sentence clearly document the criteria and checklist for promoting a beta to production. This aligns well with the PR’s objective.
52-52: Beta‑label removal step well documented.This line explicitly covers removing all beta labels in companion docs and merging once Google approves—directly addressing the PR objective.
| - Due to the app's complexity, not all features can be tested exhaustively during this phase. | ||
|
|
||
| ### Weekly beta releases | ||
|
|
||
| - Every week, the latest version of the `main` branch is pushed to the **open beta** channel. | ||
| - Every Saturday at 9pm PST, the latest `main` build is pushed to the **open beta** channel. | ||
| - Before that cutoff (Friday or Saturday), update the beta changelog to highlight new features and breaking changes. |
There was a problem hiding this comment.
I wonder if we can't add a flag like we do for 'beta' in companion docs to identify this as a 'task'. This is blend into information about something fully automated.
There was a problem hiding this comment.
hmm well not everything is actually documented in the companion app docs, generally I try to go by the most recent commits that were merged and anything user facing I try to highlight and call out where they may see it like in settings. Most of the features are easy to write for but sometimes they are complex and 1 sentence may not be enough :) For something more important like a Breaking Change we probably def want to flag for that
Proposed change
Add more details around internal, open beta and production release processes
Type of change
Checklist
Additional information
Summary by CodeRabbit