wiki:ReleaseEngineering

Owner: jreed

Date next review scheduled: September 23, 2010

This page documents the BIND 10 release engineering schedule and processes for stable or production releases of individual components and BIND 10 as a whole. See DevelopmentReleaseEngineering for the procedures for the development, snapshot-style releases.

Please don't edit this page without prior discussion (other than minor grammar or spelling improvements).

Note this currently doesn't go into great detail on tools, technologies, code review, et cetera nor coordination with public relations and marketing, for example.

Let's not over-engineer our processes. Let's commit to yearly process review and tool up as necessary, instead of putting a heavyweight process in place that gets in the way.

The generic release engineering notes are at ReleaseEngineeringNotes.

The log of release engineering history is at ReleaseEngineeringHistory.

Quick summary: Defined timeline for releases using continual builds, community testing, and benchmark performance targets to supplement release progress.

Individual BIND 10 components for major releases

  • Daily snapshots, build reports, and benchmark results from current development always available.
  • Defined 6 month schedule for every release. The release cycle is between 30 days and 60 days. The start of the cycle will based on a time-based schedule, but new features may also start the cycle sooner. (Note that critical bugs or security fixes don't affect the beginning of the "major release" cycle but only for "minor" releases.)
  • 60 days before scheduled release date, release engineer announces intent to begin cycle in 15 days. This announcement will be sent to developers and will provide expected schedule and known proposed features and changes (and point to URL for existing complete ChangeLog?).
  • New ticket is assigned for tracking this major branch. Desired features (not yet in the main code) and bugs will be linked to this ticket.
  • 15 days to integrate new changes before code freeze.
  • No significant new changes to code.
  • No API or ABI changes allowed.
  • Around 50 days before scheduled release data, an "alpha" is released. The "alpha"" release includes tagging, tarball with updated version numbering and release notes, automated testing, checksums, PGP signatures, and announcement email to "developers" and "testing" lists.
  • 45 days before scheduled release date, temporary code freeze and branching for new release.
  • New release branch added to TestFarm and BuildFarm for daily snapshots, build reports, and benchmark results.
  • Commits to new stable branch must be pre-reviewed. Only minor changes, improved documentation, bug fixes, and security fixes allowed.
  • "beta" released one day after the branching. The "beta" release includes tagging, tarball with updated version numbering and release notes, automated testing, checksums, PGP signatures, and announcement email asking for testers.
  • At least one "beta" release with 100 installs (hopefully within one week of use). These "installs" are reported or recorded by beta testers (maybe using "call home" version check feature).
  • Betas 2 and greater only provided if needed. Generally no new features are ever introduced after first beta.
  • At least one "release candidate" release with one week of use. The "release candidate" will include tagging, tarball with updated version numbering and release notes, automated testing, checksums, PGP signatures, and announcement email asking for testers. (ISC OPS may be just one of the "testers".)
  • Release candidate will not be done until code also passes its benchmark performance targets (TODO).
  • No changes allowed to a release candidate other than documentation and version renumbering for "official" release. This is what we intend to release, unless there are bugs. If there is a bug, then do another release candidate. No new features in a release candidate.
  • Any other changes require another "candidate" provided and announced.
  • Tickets and BuildFarm and TestFarm results will be reviewed before each alpha, beta, and release candidates are created.
  • Final release prepared. The "final release" will include tagging, tarball with updated version numbering and release notes, automated testing, checksums, and PGP signatures. This will be announced to developers for review. (Note: with the public "open" model, the public may see the "final" release before this testing and review.)
  • Final release publicly announced.

  • This final release begins the cycle for its minor releases.

Individual BIND 10 components for minor releases (stable branches)

  • Daily snapshots, build reports, and benchmark results from stable / minor branches development always available.
  • We will maintain official releases as stable branches with bug fixes and minor feature changes with the goal of no ABI/API, command line interfaces, or configuration syntax changes.
  • It will follow the basic same schedule as the major releases except with a defined 3 month schedule for every release (instead of 6 month) and no "alpha" cycle (because "alpha" is the existing release in use). The release cycle (excluding critical bug or security fixes) is usually 30 days. The start of the cycle will based on a time-based schedule, but significant bug fixes may also start the cycle sooner.

BIND 10 Suite

  • The BIND 10 suite is made up of individual components which have their own releases.
  • The BIND 10 release is composed of the latest "stable" versions of each component.
  • We will provide lists of the official versions of dependencies and components that work together.
  • Individual components will use autoconf checks to make sure dependencies are correct.
  • In some development cases, individual component changes may affect others (due to API/ABI changes for example). In this case, we will strive to provide multiple official releases at same time for corresponding components.

Post Release Review

Also known as a "Post Mortem" review.

  • Do the post release review to evaluate process and product.
  • Do this review within 20 days after release.

End of Life / Lifetime Support Policies

We do not provide support or EOL timeframes for developmental releases for alphas, betas, release candidates, etc.

For BIND 10, we won't provide support of EOL timeframes for the first two years as it is in a development phase.

The expected official EOL is to be three years for selected versions.

(TODO: need to discuss "lifetime" policies and number and type of stable/minor/security branches, etc.)

Last modified 4 years ago Last modified on May 29, 2013, 12:21:03 PM