Release Model

From SprezzOSWiki
Revision as of 15:52, 31 July 2012 by Dank (talk | contribs) (Created page with "At any time, SprezzOS can be uniquely defined by a snapshot at some previous time ''T'', plus an ordered list ''M'' of modifications since that time. The history of SprezzOS c...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

At any time, SprezzOS can be uniquely defined by a snapshot at some previous time T, plus an ordered list M of modifications since that time. The history of SprezzOS can be discretized by these M, yielding a natural sequence Ti. Certain of these Ti will mark the origin of a new branch (and thus a new M relative to T), a release.

Releases, by reducing the amount of change undergone by the distribution in a given span of time, intend to ease the lives of external developers and system administrators. They are essentially external to the development process itself, and reflect this in their rule-oriented, somewhat arbitrary natures. Each active release has costs in terms of support and maintenance. As releases diverge further and further, those costs tend to increase. Tightly-clustered releases, meanwhile, add diminishing value. A newer release will typically exhibit greater:

  • hardware support
  • software features
  • reliability of existing software (bugfixes)
  • resource consumption

while ABIs and other interfaces might have changed, at a maintenance cost for end users. Furthermore, a newer release might introduce new bugs, or eliminate necessary functionality. Ideally, every change to SprezzOS would result in a release (this is indeed possible for those building from source). Since releases have cost, however, the number of actively supported releases must be bound. Current development resources suggest that, in addition to trunk, one release (having fairly arbitrarily diverged) can be supported at any given time.

Releases will thus be motivated by:

  • Features added since last release
  • Difficulty of adding those features, in isolation, to the last release
  • Necessity of lost/broken functionality from older releases
  • Time since last release

Successive releases will have successive major numbers. Official branching is only expected to be performed from the SprezzOS trunk. Each M applied to a release increments the minor number. Whenever an M results in a new middle number for one of a release's kernels, that increments the middle number and resets the minor number.