Линус Торвальдс выпустил ядро версии 3.0-rc1. Отменено использование чётных/нечётных номеров для обозначения стабильности ядра, а третье число отдано команде стабилизации. Таким образом, следующий после этого релиз будет иметь номер 3.1, а стабильный - 3.0.1.

Версия 3.0 ядра Linux ничем особо не примечательна, кроме как обновлением драйверов.
http://linuxunited.org/4383.html

Философию затронул, как же я без неё?

в данном случае важнее, что номера будет легче автоматически парсить.

Ну кому как. Я кеды не использую.

grub2.0
gnome3.0
всё без проблем? я не про кеды, я про нулевые версии.

ИМХО просточисто  психологически спокойней

ИМХО я-бы спать перестал. И ещё напился-бы. Вспомните например KDE 4.0 

что у тебя ядро стоит 3.0.0 а не 2.6.40

> uname -sr
Linux 2.6.34.8-0.2-desktop

и я спокоен как удав.

Перенумерация не нужна.

нужна. для тех, кто ленивый. скрипту проще парсить. например sed вообще арифметики не знает, а следовательно не может отличить чётную от нечётной. Администратору абсолютно фиолетово, что сделали небольшую перепилку ядра, добавив пару фиксов, которые ему и не нужны. Но вот новые версии отслеживать надо. Если вам это не нужно - вы может просто не заниматься этим.

По своей сути версия 3.0.0 не будет отличаться от 2.6.40 - различия будут только в изменении номера ветки

Перенумерация не нужна.
Если только в планах кардинальных изменений и важных нововведений.

Линус Торвальдс опубликовал в списке рассылки разработчиков Linux-ядра сообщение, в котором кроме обычного напоминания о необходимости своевременной отправки патчей для будущей версии Linux ядра указал на то, что число выпусков в рамках ветки 2.6.x уже слишком велико, поэтому возможно имеет смысл выпустить вместо версии 2.6.40 релиз 2.8.0. В отличие от ранее возникавших дискуссий, не ушедших дальше обсуждений, переход к новой нумерации на этот раз можно приурочить к празднованию двадцатилетия с момента появления ядра Linux и завершению работы по реорганизации кода, связанного с платформой ARM.

В процессе обсуждения некоторые разработчики склоняются к мысли, что вместо 2.8.0 следует выпустить релиз 3.0.0 или кардинально реформировать процесс нумерации ядра. Тем не менее для обеспечения совместимости с различными системами сборки и системными скриптами в дистрибутивах, общее представление X.Y.Z планируется сохранить. Например, возможна привязка номеров к дате выпусков без изменения привычного трехзнакового представления (номер 3.1.1 можно рассматривать, как первый выпуск в 2011 году, 3.1.2 - как второй и т.п.). Другой вариант - отбрасывание префикса "2.6." и разбиение последних двух цифр номера (вместо 2.6.39 использовать версию 3.9, а вместо 2.6.40 - 4.0). Некоторые разработчики предлагали перейти к формату версий "Год.Номер.Корректирующий_номер" или "Год.Месяц.Корректирующий_номер" (например, 2011.0.0, 11.0.0 или 2011.5.0), но подобные схемы были отклонены, как нарушающие привычное представление версий ядра.

В итоге, был выделен наиболее оптимальный вариант, который скорее всего будет принят в качестве окончательного. В соответствии с предложенным методом, вместо версии 2.6.40 будет выпущен релиз 3.0.0, при этом вторая цифра будет указывать на номер версии, а третья на корректирующий выпуск. Т.е. после 3.0.0 будет представлен выпуск 3.1.0, за ним 3.2.0, 3.3.0 и т.д. В процессе накопления патчей корректирующие обновления будут представлены как 3.0.1 вместо 2.6.40.1, 3.0.2 вместо 2.6.40.2 и т.д. В будущем не исключено появление ветки 4.x.y, в качестве критериев выпуска которой названы нарушающие совместимость кардинальные изменения или накопление примерно 40 обычных версий. Цифра 40 выбрана, так как при текущем темпе разработки на выпуск 40 версий уходит примерно 10 лет, таким образом версия 4.0.0 будет выпущена в 2021 году, после того как ядру исполнится 30 лет.

В релизе 3.0.0 не ожидается кардинальных изменений, связанных с глобальной переработкой ключевых подсистем или нарушением совместимости. По своей сути версия 3.0.0 не будет отличаться от 2.6.40 - различия будут только в изменении номера ветки. В 2004 был совершен уход от схемы с разделением нестабильных и стабильных веток (X.Y.Z, четная Y - стабильная, нечетная - нестабильная) в сторону непрерывного цикла подготовки новых релизов с их последующей стабилизацией путем выпуска промежуточных кандидатов в релизы. Подобная модель разработки позволяет добавлять большие новшества не ломая при этом совместимости и не создавая отдельной нестабильной ветки.

Источник — http://www.opennet.ru/opennews/art.shtml?num=30639
Главная ссылка к новости — https://lkml.org/lkml/2011/5/23/358