---------------------------------------------
mainline: 3.10-rc5 2013-06-09
stable: 3.9.6 2013-06-13
stable: 3.8.13 [EOL] 2013-05-11
stable: 3.7.10 [EOL] 2013-02-27
longterm: 3.4.49 2013-06-13
longterm: 3.2.46 2013-05-30
longterm: 3.0.82 2013-06-13
longterm: 2.6.34.14 2013-01-16
longterm: 2.6.32.61 2013-06-10
linux-next: next-20130607 2013-06-07
---------------------------------------------
https://www.kernel.org/上于20130615显示的信息.
---------------------------------------------

stable: 3.9.6 2013-06-13
stable: 3.8.13 [EOL] 2013-05-11
---------------------------------------------
Q1： EOL 是End-of-life的意思吗? 3.8.13更新于2013-05-11
3.4.49更新于2013-06-13

longterm是long-term support的意思吗?
那为什么3.4.49长期支持,3.8.13就EOL了?

Q2: 2.6.34.14和2.6.32.61版本跨度不大的(不清楚实质区别大不大).
为什么不停止对低版本2.6.32.61的支持?

Q3: 自己编译内核的话是选择stable版还是选择longterm?
选择stable的话要不要选择EOL的? 从不折腾的角度出发.

Q4: 自己编译内核的话选择版本是不是越高越好呢(stable版范围内)?
比如有一些需要高版本内核才能带来的特性体验.
----------------------------------------------
不要提示"就点Latest Stable Kernel下载按钮".
想弄清楚这些tag区别.

不要提示"stable kernel rules".
劳烦用通俗易懂的白话翻译一遍.
来个精彩的类比就再好不过了.V2EX上很多风趣回复.

求科普.谢大伙了.
唬. 在v2ex上把这些数字对齐还真不容易.

A1: 是
3.8 貌似只是个快速过渡版。如同freebsd 5.0，拖拉好几年，一直是个开发版，最后 5.3 直接出世成为5.X第一个稳定生产发行版。
A2: 2.6 的用户还不少，尤其RHEL等，旧发行版生命还未结束，至少安全更新还得继续。
版本号只是个数字，你得去看后面的 changelog
A3: 没理由选择EOL，除非你喜欢冰恋。
A4: 喜欢折腾，又不想轻易死掉，那就点「Latest Stable Kernel」就是了。
但最近两三年，最新Stable有时变化也不小，不小心也可能起不来，尤其牵涉设备和驱动大变化的时候。

顺便求教v2ex上发帖排版

回复太迅速了. 赞.

再扫盲下. ChangeLog 的 commit 是怎么排的？ 按时间顺序? 先提交应该在下面吧. 后提交的靠上吧. 比如这个 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.4.49

commit 1bcf5bcf70fb6f316d4eba792d103af602cb3514
Author: Jan Beulich <[email&/>Date: Wed Feb 6 10:30:38 2013 -0500
按 “Date: ” 来看,时间并不是顺序. 修改时间不等于合并时间.
扫盲下. 是按什么时间排的? 是pull request时间还是request merged时间.
所以问上面的问题.

研究changelog里commit排序，这个有实际意义么？

嗯, 我有kernel源码,但源码里没有".git" 所以不能 "git log kernel"
只能看文件的生成时间来推断原始出处.
按时间缩小大致范围. 然后查看commit,看我本地源码是否做出修改.
然后好确定需要合并哪些补丁.

你是自己修改内核源码？维护一些自己改写的补丁？

嗯啊. 直接 diff 和 patch 会有问题.

我猜自己装个git，或许就能从kernel.org匿名只读同步最新的git库，如此这般，要知道每一个commit就很容易了。
之前只用过svn来更新freebsd源码，
linux这边是否有提供类似途径我就不知道了。

最理想的状态是只合并kernel的commit. 我的思路是不是笨了. 我大脑只有核桃那么大, 望指点.

按时间找到原始commit. 然后git checkout commit 大概就是我本地kernel源码的出处了.

参考： Kernel.org git repositories : https://git.kernel.org/cgit/
或许，你把你自己作补丁的部分 给 git checkout 到本地一份，再 fork 出去一个自己的版本，或许就比较方便了。

嗯, 现在算是知道了. 当时图简单.现在太苦逼.
不按规范来, 后续好麻烦. 又得做出无谓的浪费.
得理清一下.然后按你说的来. 分开commit. 然后合并.
谢谢了,谢谢你的回复, 早些休息吧.