The Firefox Nightly channel

From MozillaWiki
Jump to: navigation, search
Process card
Nightly cycle tasks
Purpose Ensure maximum quality on mozilla-central
Why Regression introduced during the nightly cycle identified in Beta/Release only are costly
Results Improve quality early, ship faster, identify and fix regressions at the earliest stage possible
People involved Relman, Nightly community, Triagers

This page lists what the release management team should do during the Nightly development cycle on Desktop.

Summarized process

  1. Update nightly version in Ship-it at the beginning of the cyle
  2. Create new blank release notes in Nucleus
  3. Watch regressions during the cycle,
  4. File top crashes in Bugzilla from Socorro
  5. Watch commits and communicate to testers what needs testing
  6. Check for bugs nominated for tracking and find owners
  7. Add interesting features to release notes
  8. Create new flags in Bugzilla for the next version at the end of the cycle

Cycle details

Beginning of a new cycle

  • Update the version number on Ship-it on merge day when mozilla-central is updated with a new version number.
  • Ask releng for a push of product-details to production once we have all the locales built.
  • Copy the previous release notes template in Nucleus with the new version number. You don't have to set it as public as long as there are no note added, a 'coming soon' page will be displayed on as long as the release is created in Nucleus.
  • Update Firefox tracking flags in Bugzilla (add flags for new nightly version, deactivate tracking flags for unsupported versions)

During the cycle

  • Check for bugs nominated for tracking
  • Check bugs filed with the nightly-community keyword, those are filed by our more engaged alpha-testers and are often recent regressions
  • Find owners for tracked bugs. This is important as it gives us a chance to fix new regressions and crashes before they move to channels which have more users.
  • Track bugs related to new feature development that are aimed for their release.
  • File top crashes and newly appearing crashes from crash-stats
  • Watch all commits on mozilla-central for interesting features
    • Interesting changes should be communicated to our alpha-testers via our @FirefoxNightly Twitter account
    • Interesting changes with an end-user impact to the end user should have the relnote flag set
  • Write Release Notes during the cycle based on what is nominated to be included in release notes
  • Watch reports on Twitter, IRC and other communication channels about major regressions. Ask releng for a patch to be backed out and nightlies re-spun if the end-user impact may lead to loosing alpha testers.

End of cycle

  • Check that there is no visual regression on the What's New Page caused by template changes on or gecko changes in rendering a week before merge day
  • Ask the Bugzilla team to create status and tracking flags for the next version, ex: Bug 1444839


  • We do not maintain release notes for Firefox Nightly on Android
  • There is no what's new page for Android

See also