Release Model: Difference between revisions

From SprezzOSWiki
(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...")
 
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 15: Line 15:


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''.
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''.
==Release Matrix==
{{:Release Matrix}}
{{Handbook}}
[[CATEGORY: SprezzOS Releases]]

Latest revision as of 21:01, 5 February 2013

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.

Release Matrix

Release (recent) Date (planned/actual) Media Architectures Bug Tags Kernel libc
3 "Kleene" TBD TBD TBD 3.0.0 TBD TBD
2 "Kolmogorov" 2013-08-06 / TBD TBD TBD 2.0.0 TBD TBD
1 "von Neumann" (1.1.1) 2012-12-25 / 2013-01-13 SprezzOS-1.1.1.iso amd64 1.0.0 Linux 3.7.5 GNU libc 2.16
0 "Turing" (0.0.1) 2012-10-05 / 2012-10-08 SprezzOS-0.0.1.iso amd64 0.0.0 and 0.0.0-beta Linux 3.6.0 EGLIBC 2.13

{{#switch:|subgroup|child=|none=|#default=

}}{{#ifeq:|Template|{{#ifeq:|child||{{#ifeq:|subgroup||{{#switch:release model

|doc
|sandbox
|testcases =
|#default = {{#switch:
 |plainlist
 |hlist
 |hlist hnum
 |hlist vcard
 |vcard hlist = 
 |#default = hlist
 }}
}}

}}}}}}