Binkd 1.1a73 binaries for Win32, Win64, OS/2

Max Vasilyev написал(а) к Brother Rabbit в Jan 16 18:02:34 по местному времени:

Нello Brother!

22 Jan 16 16:03, you wrote to Konstantin Simonov:

KS>> Привычка ставить последние версии,
BR> А зачем? Вот, если что-то не работает, а в новой исправили, то есть
BR> смысл, ну, или какая-то мега нужная фича появилась...
Зато он помогает понять разработчикам, что что-то пошло не так.

WBR, Max. piwamoto!писем-нет
--- скучаю по FleetStreet'у :-(((

Max Vasilyev написал(а) к Pavel Gulchouck в Jan 16 18:06:18 по местному времени:

Нello Pavel!

22 Jan 16 14:46, you wrote to All:

PG> Я надеюсь, все понимают, что 1.1.x - это develop-ветка, в которую
Ага

PG> это снапшот исходников из репозитория. Их можно использовать для
PG> помощи разработчикам в тестировании, но не нужно ставить на раздающие
PG> узлы, чтобы не страдали даунлинки.
А на хосте у меня до сих пор 0.9.11

Обновляться или "работает - не трогай"?

WBR, Max. piwamoto!писем-нет
--- скучаю по FleetStreet'у :-(((

Pavel Gulchouck написал(а) к Konstantin Simonov в Jan 16 20:25:28 по местному времени:

Нi Konstantin!

23 Jan 16, Konstantin Simonov ==> Pavel Gulchouck:

PG>> Обе эти ветки прекратили развитие в том смысле, что туда не
PG>> добавляются новые фичи. Но обе они не прекратили развитие в смысле
PG>> исправления ошибок.

KS> Спасибо, очень хорошо объяснил. Но из этого непонятна ситуация, возникшая с новыми версиями в части их
KS> неработоспособности. Если нет новых фич, то не может ни с того ни с сего возникнуть проблема с работой программы.
KS> Вероятно, происходит какая-то существенная оптимизация кода, т.к. простое исправление ошибки не может привести к фатальным
KS> последствиям в уже довольно стабильно работающей версии 1.1a-73.

Цикл жизни binkd такой.
Есть основная (девелоперская) ветка, trunk, там появляются все новые фичи. Сейчас это 1.1, и каждый коммит там автоматически получает очередной номер, например, 1.1a-73, следующий коммит получает номер 1.1a-74 и т.д. Эти номера нужны исключительно для того, чтобы при багрепортах лучше понимать, на какой именно версии проявилась та или иная бага.
Через некоторое время, когда фичей набирается достаточно много, от develop-ветки отделяется стабильная ветка. В ней добавление новых фичей замораживается, делаются только багфиксы. Develop-ветка при этом получает следующий номер. То есть, после отделения 1.1-stable develop-ветка станет 1.2. Через некоторое время, когда в 1.1-stable будут исправлены основные баги, будет выпущен релиз 1.1.0. Следующие релизы в этой ветке будут 1.1.1, 1.1.2 и т.д.

На сейчас есть две таких стабильных ветки: 0.9 (последний релиз здесь 0.9.11) и 1.0 (последний релиз 1.0.4).
Появится ли когда-нибудь 1.1-stable - неизвестно. Может быть, и нет.

В ветке 1.1 вполне могут появляться неработающие сборки. Какие-то снапшоты могут работать вполне стабильно, а после этого следующие могут не работать вообще - это нормально для develop-ветки.

KS> Но меня не оставляют сомнения в целесообразности поддержки двух веток программы. Если с появлением каждого существенного
KS> новшества заводить новую ветку, можно дойти до абсурда. Опять сравню с hpt. Мало кому нужны все фичи тоссера, но
KS> большинство пользуются версией current. Так и с мейлером. Пусть фичи будут, но новшества не должны никому мешать и одной
KS> ветки должно быть достаточно. :)

При появлении существенных новшеств заводить новую ветку и делать следующую major version - это общепринятая практика. Как и поддержка двух-трёх последних стабильных веток.
Новые фичи часто приводят к существенным изменениям в коде (а значит, к новым багам) или к увеличению потребляемых ресурсов или к отказу от совместимости с какими-то системами или старыми версиями OS. И пользователи, которым эти новые фичи не нужны, не должны от их появления страдать. Поэтому поддерживаются старые стабильные ветки без этих фичей.

Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5