X-Git-Url: https://git.decadent.org.uk/gitweb/?p=debian-kernel-talk.git;a=blobdiff_plain;f=index.html;h=2f131ff8efefb492e1b58abf8f500addf50d4b97;hp=546aa047b0752efc8449c7b80e70e048d6f4fde5;hb=4ae4e65de0ba8481d4bdc4577b75088a69d23db0;hpb=c8b14f5b155cd82efe7a494daede15e5c9f3b612
diff --git a/index.html b/index.html
index 546aa04..2f131ff 100644
--- a/index.html
+++ b/index.html
@@ -111,7 +111,63 @@
-
Linux release model
+
Linux release model (1)
+
+ The old model:
+
+
+ -
+ Each stable release had even second component. Bug fixes and
+ minor features in stable releases with third component
+ incremented (e.g. 2.4.27)
+
+ -
+ Major development done separately, resulting in series of
+ unstable releases with odd second component (e.g. 2.5.50)
+
+ -
+ After a year or two, development resulted in a new stable
+ release
+
+ -
+ Problem: users waited years for new features, and then got many
+ more changes all at once. Particularly bad in the 2.4-2.6
+ transition.
+
+
+
+
+
+
Linux release model (2)
+
+ The new model:
+
+
+ -
+ Development results in a new stable(-ish) release every 2-3
+ months
+
+ -
+ git (and previously BitKeeper) made distributed development
+ and testing a lot easier
+
+
+
+ -
+ Each 2.6.x release has stable update branch; releases
+ numbered 2.6.x.y
+
+ -
+ Usually closed shortly after next stable release, but may
+ continue as a 'longterm' branch (e.g. 2.6.32.y)
+
+
+
+ -
+ Linux 3.0 doesn't change this, except that x is now
+ the second component and y is the third
+
+