Skip to content

WIP-0011: Release Scheduling Process

Introduction

This WIP proposes a lightweight release scheduling process for Whitebox alpha and flight releases.

The goal is to make release weeks predictable: create a known-good release candidate early, reserve time for testing and reviews, and avoid risky last-minute changes on flight day.

This is a proposed default process, not an enforcement mechanism. Maintainers can adjust it for unusually small or urgent releases, but should make deviations explicit.

Goals

  • Give maintainers a simple default timeline for alpha/flight releases
  • Create space for testing, review, firefighting, and bug fixes before flight day
  • Tag the final alpha early enough that it can be used as the known-good flight build
  • Reduce pressure to merge risky last-minute fixes during the flight window

Proposed Timeline

The default schedule starts about one week before the planned release or flight.

T-7 Days: Create Release Candidate Branch

  1. Create an RC branch from the intended release base.
  2. Start feature freeze for the release.
  3. Open release-window testing tickets for the areas that must be verified.
  4. Identify owners for testing, review, and release notes.

After the RC branch is created, only release-critical changes should be accepted into it. New features continue on the normal development branch for a later release.

T-6 to T-4 Days: Testing and Review Window

Use the early release window to verify the RC branch while there is still time to respond calmly.

  • Run the planned testing tickets against the RC branch.
  • Review any release-critical fixes with explicit reviewer time reserved.
  • Keep changes small and directly tied to release readiness.
  • Record known issues and decide whether they block the release.

T-3 to T-2 Days: Firefighting and Bug-Fix Buffer

Reserve this period for fixes discovered during testing.

  • Merge only bug fixes that reduce release risk.
  • Re-run the affected testing tickets after each fix.
  • Avoid broad refactors, dependency updates, or unrelated cleanup.
  • Escalate any unresolved blocker early enough to delay the release if needed.

T-2 to T-1 Days: Flight-Testing Buffer

Use the final pre-flight window for the closest practical rehearsal of the flight setup.

  • Test the candidate on representative hardware.
  • Verify plugin and device behavior needed for the flight.
  • Confirm rollback instructions and the expected tagged release.
  • Do not introduce non-critical changes during this buffer.

T-24 Hours: Tag Final Alpha

Tag the final alpha release at least 24 hours before the flight.

The tagged alpha is the known-good build for flight day. Any fixes after this point should be treated as exceptional and should require an explicit decision that the risk of changing the build is lower than the risk of flying with the known issue.

Flight-Day Policy

On flight day, use the known-good tagged alpha release by default.

Avoid risky last-minute fixes unless the issue is critical for safety, data capture, or the core purpose of the flight. If a critical fix is required:

  1. Keep the patch as small as possible.
  2. Review it explicitly.
  3. Test the affected path on the flight hardware.
  4. Tag or otherwise record the exact build that will fly.
  5. Communicate the decision and rollback plan to everyone involved in the flight.

If the fix cannot be reviewed and tested in time, the default decision should be to fly the known-good tagged release.

Release Checklist

  • [ ] RC branch created about one week before release/flight
  • [ ] Feature freeze announced from RC branch creation
  • [ ] Release-window testing tickets opened and assigned
  • [ ] Explicit reviewer time reserved for release-critical fixes
  • [ ] Firefighting / bug-fix buffer protected from unrelated work
  • [ ] Flight-testing buffer completed on representative hardware
  • [ ] Final alpha tagged at least 24 hours before flight
  • [ ] Flight-day build and rollback plan communicated