Какие проекты с открытым исходным кодом используют нечетно-неустойчивый/стабильный стиль управления версиями

Один из моих коллег сказал мне сегодня, что некоторые проекты используют странный, ИМХО, способ версии для своих версий. Если выпуск нестабилен, второстепенная версия является нечетным числом, например. 1,3, 1,5. С другой стороны, стабильные выпуски имеют даже незначительный номер версии, например. 1.2, 1.4.Какие проекты с открытым исходным кодом используют нечетно-неустойчивый/стабильный стиль управления версиями

Сначала я не мог поверить своим ушам, это казалось нереальным. Затем Wikipedia просветил меня, что это практика, приходящая от сообщества ядра Linux, хотя кажется, что (?) Была недавно удалена.

Через несколько часов я читаю Programming Ruby's preface и что я вижу? Ruby использует одно и то же соглашение для номеров версий.

Каков ваш опыт? Какие (с открытым исходным кодом) проекты/продукты, о которых вы знаете, используют эту схему управления версиями? Есть ли простой способ быстро понять это, если они соблюдают это соглашение? Это популярно? Я начал разработку программного обеспечения чуть больше 3 лет назад и раньше не слышал об этой практике.

Спасибо за ваши ответы.

источник

2009-08-12 Ionuț G. Stan

Ядро linux отбросило эту практику с начала ядра 2.6 в 2003 году (то есть 2.4 была последней стабильностью с соответствующей ветвью развития 2.5). Я просто смотрел на то, что я писал в моих master thesis о проектах в целом:

Раскола между стабильным и в ветви разработки является очень распространенным стратегии в проектах с открытым исходным кодом, хотя некоторые используют больше {примечание}. Числа высвобождением, используемые затем также часто с использованием чет/нечет схему на виде аЬс где а основной выпуск число, Ь даже для стабильной и нечетных для развития и с представляет собой последовательность номер версии (иногда a дополнительный d также используется).

{footnote} Например, разработка XEmacs разделена между тремя ветвями: стабильными, гамма и бета-версиями. Debian использует экспериментальные, неустойчивые, тесты и стабильные.

Для получения более подробной информации о ядре linux вы можете прочитать главу «Разделы развития Linux 2.2.4».

источник

2009-08-12 14:20:57 hlovdal

Спасибо hlovdal. Хороший предмет для магистерской диссертации. –

Многие проекты с открытым исходным кодом действительно использовали это, но большинство из них изменилось на другие методы. Например, ядро Linux использовало это (довольно давно). Недавно Mesa (стек OpenGL с открытым исходным кодом для Linux) прекратил использовать этот метод с версией 2.5.

ИМХО, все выпуски должны быть относительно стабильными. Если он еще не стабилен, он должен быть альфа-или бета-версией. Например, релиз KDE 4.0 был ужасной ошибкой. 4.0 должно было быть альфа. 4.1 должен был быть бета-версией. 4.2 был первым действительно полезным выпуском.

источник

2009-08-12 14:23:57 Zifre

Хорошо, я бы сказал, что для проектов, которые используют эту схему управления версиями, выпуск версии с нечетным младшим номером служит той же цели, что и маркировка релиза как бета-версии. KDE 4.0, однако, это другое дело, поскольку в номере версии ничего не было, что означало его нестабильным. – sepp2k

@ sepp2k: в то время как эта схема управления версиями работает с той же целью, что и бета-версия, вы не можете ожидать, что пользователи узнают об этом. Многим пользователям нравится обновлять программное обеспечение и устанавливать (например) CoolNewApp 3.7 над CoolNewApp 3.6, так как не сразу очевидно, что 3.7 будет неустойчивым. – Zifre

Обычно политика версий для любого проекта хорошо документирована. Кроме того, я не вижу, как использование греческих букв является чем-то более интуитивным, чем использование арабских цифр. –

GTK + и GNOME тоже использование это схема управления версиями. Обратите внимание, что ruby больше не использует эту схему с 1,9 (что является стабильным).

источник

2009-08-12 14:26:54 sepp2k

Спасибо за информацию о Ruby. По-видимому, люди отказываются от этой конвенции. –

На самом деле причина изменения схемы нумерации релизов в Ruby еще более неясна: при выполнении простого сравнения лексикографической строки «1.10» сортирует * до * «1.8», поэтому было решено выпустить то, что * было бы * 1.9.x как 1.9.0-x (так, например, что было бы 1.9.2 стало 1.9.0-2) и что было бы 1.10.x как 1.9.x + 1 (так, например, что бы было 1.10.1 стал 1.9.2). Таким образом, первая стабильная версия Ruby 1.9 не была Ruby 1.9.0 (выпущена в свет в начале 2007 года), но Ruby 1.9.1 (выпущен в феврале 2009 года). –

Какие проекты с открытым исходным кодом используют нечетно-неустойчивый/стабильный стиль управления версиями

ответ

Смежные вопросы