wiki:OtherReleaseExamples

This page just documents some release processes by other projects. (Moved this from main ReleaseEngineering page.)

OpenBSD-style Release Schedule

  • Daily snapshots
  • Defined 6 month schedule for every release
  • Release cycle is simply a fine-tuning period
  • first 2 weeks (at beginning of cycle which is at end of previous release):
    • Unlock tree, minor development
    • Normal development cycle
    • Big stuff committed now
  • Approximately 4 to 6 weeks before known release date:
    • 2 to 3 weeks:
      • Slowdown, check for regressions
      • no major changes to significant parts of tree
      • API / ABI locks (surprise date)
    • 2 to 3 weeks:
      • early package builds start
      • tree locks (any changes require approval)
      • developers run tests
      • keep developers testing of tree -- not allowed to work on new code
    • 2 to 3 days:
      • tag / branch trees
      • unlock tree for next cycle

FreeBSD-style Release Schedule for "stable"

  • "stable" branch releases done at approximately 6 month to one year intervals (documented as 4 month intervals)
  • process begins 110 to 135 days days before anticipated release date (documented as 45 days)
  • 15 days to integrate new changes before code freeze
  • MFC acronym: "Merge from -current" (merge from HEAD), code developed and tested in HEAD first.
  • 30 days to 15 days before anticipated release: commits to stable branch must be pre-approved by release engineering team. Change may include: bug fixes, documentation updates, security fixes, adding new device IDs or minor device driver changes, or changes as justified by releng team.
  • at 15 days before anticipated release: code freeze begins and release candidate released
  • release engineering team in communication with security team, documentation maintainers, and port (third party software packaging) maintainers.
  • one release candidate released each week (for last fifteen days)

X.org-style Release Process

X.org doesn't have the policies and schedule defined nor documented. X.org as a whole X11 is based on over a hundred different components (called packages or modules) which have their own developers and releases. There is no defined schedule or cycle. And no regression testing plan or quality control and no policy for communication with other developers. No individuals are responsible. No policies on locking the tree and no locking APIs/ABIs. Only fairly loose guidelines.

  • For individual components:
    • For most components, any individual with SSH privilege may decide to roll out a new release of some component without any discussion.
    • Individual developer may or may not work with others to decide when to release.
    • No official policy to do beta releases or even to announce intent to release.
    • Components may sync up with whatever components are convenient (so could be old releases or development code from git master).
    • APIs may change that break other existing official components.
    • Increase number (like in configure.ac) for release version.
    • Private and informal testing.
    • Tag in git.
    • Create tarballs and upload tarballs.
    • Create checksums.
    • Announce release with PGP signed email to xorg-announce.
  • For xorg-server:
    • Usually a two or three month cycle.
    • Sometimes announcements of intent to "bundle" up a new xorg-server is done
    • Various fixes from git master are hand-selected to pull into it.
    • Sometimes announcements of beta testings of the release are announced.
    • Informal testing.
    • Attempt is made to avoid breaking ABIs.
  • For X.org X11 as a whole.
    • This release basically identifies the versions of the components that work together -- even if they aren't the latest versions blessed by the interested component developers.

The end result is that third parties and vendors have to do their own quality control, patching, and preparation to provide their own X.org. Commonly, new component releases will be incompatible with other official components due to developers working only with old, custom, or git master (bleeding edge) dependencies -- or lack of full X.org testing. As a common example, new xorg-server releases often break several video drivers.

Last modified 8 years ago Last modified on Jun 16, 2009, 9:45:07 PM