Fill in brief overview of Linux release model
authorBen Hutchings <ben@decadent.org.uk>
Wed, 27 Jul 2011 17:16:43 +0000 (19:16 +0200)
committerBen Hutchings <ben@decadent.org.uk>
Wed, 27 Jul 2011 18:07:20 +0000 (20:07 +0200)
index.html

index 546aa04..2f131ff 100644 (file)
 </div>
 
 <div class="slide">
-  <h1>Linux release model</h1>
+  <h1>Linux release model (1)</h1>
+  <p>
+    The old model:
+  </p>
+  <ul class="incremental">
+    <li>
+      Each stable release had even second component.  Bug fixes and
+      minor features in stable releases with third component
+      incremented (e.g. 2.4.27)
+    </li>
+    <li>
+      Major development done separately, resulting in series of
+      unstable releases with odd second component (e.g. 2.5.50)
+    </li>
+    <li>
+      After a year or two, development resulted in a new stable
+      release
+    </li>
+    <li>
+      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.
+    </li>
+  </ul>
+</div>
+
+<div class="slide">
+  <h1>Linux release model (2)</h1>
+  <p>
+    The new model:
+  </p>
+  <ul class="incremental">
+    <li>
+      Development results in a new stable(-ish) release every 2-3
+      months
+      <ul class="incremental">
+       <li>
+         git (and previously BitKeeper) made distributed development
+          and testing a lot easier
+       </li>
+      </ul>
+    </li>
+    <li>
+      Each 2.6.<var>x</var> release has stable update branch; releases
+      numbered 2.6.<var>x</var>.<var>y</var>
+      <ul class="incremental">
+       <li>
+         Usually closed shortly after next stable release, but may
+         continue as a 'longterm' branch (e.g. 2.6.32.<var>y</var>)
+       </li>
+      </ul>
+    </li>
+    <li>
+      Linux 3.0 doesn't change this, except that <var>x</var> is now
+      the second component and <var>y</var> is the third
+    </li>
+  </ul>
 </div>
 
 <div class="slide">