[bind10-dev] release engineering schedule rough proposal

[Jeremy C. Reed]

This is a rough proposal for release engineering schedule and
processes for individual components and BIND 10 as a whole.
Note this doesn't go into great detail on tools, technologies, code
review, et cetera nor coordination with public relations and
marketing, for example.

Please send your opinions and examples. If you are a potential
third party user or packager of BIND 10, please share your thoughts
on how this will work within your own release engineering processes.

More details to discuss and cover are listed at
http://bind10.isc.org/wiki/ReleaseEngineering and
http://bind10.isc.org/wiki/EngineeringBits
(The following has not been added to the wiki yet.)

Quick summary: Defined timeline for releases using continual
builds 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.

 * 40 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" list.

 * 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-approved. Only minor
 changes, improved documentation, or bug/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 one week of use.

   * Betas 2 and greater only provided if needed.

 * 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.

   * Release candidate will not be done until code also passes its
   benchmark performance targets (TO DISCUSS LATER).

   * No changes allowed to a release candidate to a release other
   than documentation and version renumbering for "official" release.

   * Any other changes require another "candidate" provided and
   announced.

   * Release candidate will be successfully ran on official ISC
   servers as assigned and maintained by ISC OPS.  (This may be
   skipped when the new release has ABI or API interface
   incompatibilities with existing official BIND 10 components.)

(TODO: need to discuss this more: how will components be usable individually
and how will individual releases affect other components?)

 * 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 (and not publicly) for review.

(NOTE: ISC's existing current processes for other software is mostly
private development and the release engineering process includes
testing and review of the final release too. But with the public
"open" model to be used for BIND 10, 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). 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.

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

== 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.

  (To discuss this later...)

Jeremy C. Reed
ISC