Skip to content

developer-checklist.md

Latest commit

 

History

History
85 lines (65 loc) · 4.43 KB

developer-checklist.md

File metadata and controls

85 lines (65 loc) · 4.43 KB
Raw

Developer Release Checklist

This checklist is for developers. It summarizes what you (as a contributor/feature owner) should do before the scheduled merges in our release train:

  • main → beta
  • beta → release

For the full release-driver process (branch locks, announcements, publishing), see Release → Release Process.

Ongoing (between merges)

Do these as part of regular development:

  • Identify potential uplifts early
    • Add risk and user impact notes to the issue/PR; ensure the fix lands on main and bakes on Daily first — see Uplifts and Uplift Criteria
  • Strings and translations
    • Avoid late string changes; if unavoidable, keep them small, so translators can catch up
    • Prefer not changing localizable strings for uplifts
    • Follow Changing translations in this repository only when truly necessary
  • Quality signals you own
    • Watch crash/ANR reports and GitHub issues for your area of work and investigate regressions
  • Project management
    • Keep your issues in the project up to date (assignees, labels, status) and link PRs to issues
    • Ensure your issues are added to the project sprint board and assigned to the current sprint
    • Review the sprint board regularly and pick up backlog items as capacity allows, especially bugs and regressions
    • When reviewing external contributions:
      • Add the issue to the appropriate parent issue if not done already (e.g. [EPIC] Mobile Foundations QX 20XX)
      • Add the issue to the project sprint board and assign it to the current sprint

Before main → beta (developer responsibilities)

Note

A one-week Soft Freeze occurs before merging main into beta.

During soft freeze:

  • Avoid landing risky code changes
  • Do not enable feature flags that are currently disabled

Goal: Changes on main are safe to expose to a broader audience.

  • Feature flags
    • Ensure flags match the rules for beta
      • New features are disabled by default unless explicitly approved for beta
      • Not-ready features must be disabled
    • Prepare and merge a PR on main with necessary flag changes (before soft freeze starts)
  • Translations
    • Ensure translation updates needed for your features are merged to main
    • If no Weblate PR is pending, trigger one and help review it (fix conflicts if needed)

Before beta → release (developer responsibilities)

Goal: Changes on beta are safe for general availability.

  • Feature flags
    • Verify flags align with rules for release
      • Features are disabled unless explicitly approved for release
      • Not-ready features remain disabled
    • If changes are required, open a PR on main and request uplift to beta following the criteria in Uplift Criteria
  • Translations
    • No new string changes at this stage; confirm your changes don’t introduce them
  • Stability checks you can influence
    • Review crash/ANR reports and GitHub issues for changes affecting beta and release
    • Investigate regressions and propose fixes if needed
    • Ensure your changes have been tested on beta and address any issues found

Optional: PR checklist snippet

Paste the following snippet into your PR description to help reviewers and release drivers verify readiness for merge:

- [ ] Feature flags set according to target branch rules ([beta](../release/RELEASE.md#feature-flags) / [release](../release/RELEASE.md#feature-flags))
- [ ] Tests added/updated; CI green on affected modules
- [ ] No new localizable strings (or justified and coordinated)
- [ ] Translations accounted for (Weblate PR merged or not required)
- [ ] Uplift template with risk/impact notes filled out if proposing uplift ([criteria](../release/RELEASE.md#uplift-criteria))

After merges (what developers should verify)

  • Validate outcome for your changes
    • Watch crash/ANR and error reports for regressions related to your changes after rollout
    • Be prepared to propose/prepare a hotfix via the uplift process if necessary

Note

Merge-day coordination (branch locks, Matrix announcements, running scripts) is handled by release drivers. See Merge Process for details.