После двух лет разработки состоялся (https://www.openssl.org/blog/blog/2018/09/11/release111/)&nb...релиз библиотеки OpenSSL 1.1.1 (https://www.openssl.org) с реализацией протоколов SSL/TLS и различных алгоритмов шифрования. Новая ветка включает изменения, нарушающие обратную совместимость на уровне API. Поддержка выпуска OpenSSL 1.1.1 будет осуществляться (https://www.openssl.org/policies/releasestrat.html) в течение пяти лет.
Основные новшества (https://www.openssl.org/news/openssl-1.1.1-notes.html) OpenSSL 1.1.1:
- Поддержка TLS 1.3 (https://www.opennet.me/opennews/art.shtml?num=49126), который представляет собой улучшенную версию протокола TLS и отличается удалением устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, не-AEAD шифры, статический обмен ключами RSA и DH, указание unix-времени в Hello-сообщениях и т.п.), работает только в режиме forward secrecy (компрометации одного из долговременных ключей не позволяет расшифровать перехваченный сеанс),
обеспечивает более высокую производительность, поддерживает режим 0-RTT (устраняет задержки при согласовании соединений), поддерживает
потоковый шифр ChaCha20 (http://cr.yp.to/chacha.html), алгоритм аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), ключи аутентификации на основе цифровых подписей Ed25519, HKDF (https://en.wikipedia.org/wiki/HKDF) (HMAC-based Extract-and-Expand Key Derivation Function), ключи на основе алгоритмов x25519 (https://en.wikipedia.org/wiki/Curve25519) (RFC 7748 (https://tools.ietf.org/html/rfc7748)) и x448 (RFC 8031 (https://tools.ietf.org/html/rfc8031));- Настройки конфигурации перенесены в файл configdata.pm;
- Обеспечена возможность использования в сборочном скрипте Configure переменных для утилиты make в стиле GNU;
- Новый модуль STORE (OSSL_STORE);
- Определены пространства имён OSSL и OPENSSL, реализованные в виде префиксов;
- Добавлена поддержка формирования ключей RSA на основе более чем двух случайных простых чисел (multi-prime, RFC 8017 (https://tools.ietf.org/html/rfc8017));
- Реализованы криптографические хэши SM3 (GB/T 32905-2016) и SM4 (GB/T 32907-2016), стандартизированные для учреждений Китая;- Поддержка расширения TLS для согласования максимального размера фрагмента;
- Поддержка алгоритма симметричного блочного шифрования ARIA (https://ru.wikipedia.org/wiki/ARIA_(%D0%BA%D1...
- Поддержка алгоритма хэширования SHA3;
- Поддержка хеш-функции SipHash;
- Переписан движок devcrypto;
- Значительная переработка встроенного генератора псевдослучайных чисел.
URL: https://www.mail-archive.com/openssl-announce@openssl.o...
Новость: https://www.opennet.me/opennews/art.shtml?num=49255
А в RHEL даже 1.1.0 не завезли.
Комментарии на офсайте по этому поводу:
потому что он нахрен не нужен. ну кроме больных, считающих, что чем больше цифирка тем круче шифрование.а вот поломать совместимость с чем-то, что, ну надо же, не использует модных-современных шифров (и вполне надежно защищено другими способами - периметром, внутренней аутентификацией и т д) - мы совершенно не хотим без острой необходимости.
TLS 1.3 очень нужен.
Смотрю количество скачиваний апача и nginx на codeit.guru для RHEL/CentOS и диву даюсь, что не завозят даже 1.1.0 штатно.
Где логика? В 1.1.0 tls 1.3 нет. Он есть в 1.1.1, который релизнулся буквально сегодня. Зачем тащить в RHEL 1.1.0, если это и новый tls не даст, и совместимость сломает?
Очень простой ответ: новые шифры, новые фичи. 1.0.2 же появился в RHEL взамен 1.0.1, появился ALPN.
Даже на попеннете нет 1.3, а вы говорите о тырпрайзе.
А можно для нуба кратко объяснить зачем TLS 1.3 нужен? Что он дает админу или конечному потребителю? Я сам сетевик, в глубокие глубины работы http-серверов и https не залезал, дальше чем поставить apache для nextcloud/wordpress с lets encrypt чтобы в браузере открывалось не вникал.
А прочитать первый абзац в статье не можете?>>Поддержка TLS 1.3 (https://www.opennet.me/opennews/art.shtml?num=49126), который представляет собой улучшенную версию протокола TLS и отличается удалением устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, .....
режим - forward secrecy
Perfect forward secrecy уже давно в ходу начиная tls 1.0 и шифрами использующими DH
Только теперь это единственный возможный режим. Раньше нужно было прикладывать усилия чтобы поотключать не-pfs шифры, это делали единицыи pfs по факту не было.
умелец, умудрившийся настроить сервер так, чтобы выбрался не-pfs шифр или кто-то третий заставил сдаунгрейдиться протокол при более-менее нормальном софте у клиента (хотя бы 2016го года выпуска) - прое%#т ваши данные еще миллионом других, гораздо более простых путей, например, они просто будут скачаны всеми желающими через http://site/backup/ (где будет даже индекс. умения потребны примерно одного порядка)а теперь да - "единственно возможное ненужно", и если ты, внезапно, оказался в месте, где pfs наxeр тебе не вcpался, но его там и нет - то слососи тyнцa, что ж ты такой нешифровано-непродвинутый, не будет с тобой хипста-сайт разговаривать.
хотя эти котики нахрен, скорее всего, никому не сдались, и шифрование там для гуглялочки.
объясняю: вам - низачем.
админу локалхоста и конечному потребителю котиков он ничего и не дает.хаксор васья не сможет расшифровать ваших котиков, выливаемых на нёхклауд (на самом деле он этого не сможет по тридцатитрем причинам, причина первая - он не умеет даже подключиться к вашему кабелю, не сломав вам сеть), даже если вы не используете модный мутный шифр chacha.
если вы - резидент шпионской сети иностранного государства, только прикидываетесь белым и пушистым админчегом локалхостика - то, теоретически, если вы успели с его территории унести ноги и ректальный криптоанализатор вам не грозит, tls1.3 способен слегка застраховать вас от явных глупостей в конфигурациях серверов, которые понапихал туда проспанный вами внедренный агент (потому что по ошибке это сделать просто невозможно), и сделать кратковременный успех товарищ майора, перехватившего ваши сессионные ключи слишком поздно, достаточно бесполезным для дела.
но грамотно настроенный сервер с tls>1.0 в общем-то ничем не хуже, а tls=1.0 - весьма эфемерно хуже.
Шанс присесть на бутылочку явно выше, чем шанс взлома товарищ-майором-фсб tls1.0, настроенного на от'сь, а не с заведомо диверсионной целью.
Очень просто: новые шифры, новые фичи. 1.0.2 же появился в RHEL взамен 1.0.1, появился ALPN.
от этого alpn хотя бы теоретическая польза есть (правда, практическая есть только если alpn у гугля/ставосьми других вонючих cdn с которых альтернативно-одаренный разработчик заставляет тебя грузить всякий мусор, но там нет редхата, там гугль либо последняя убунточка - а с основным сайтом, на который тебя угораздило зайти, видимой глазу пользы не будет) От 111 - никакой вообще.
кому нужен? Ушибленным цифирками версий, неспособным понять, что он практически ничего им лично не добавит к безопасТносте, зато очень даже убавит совместимости?> Смотрю количество скачиваний апача и nginx на codeit.guru для RHEL/CentOS
озабоченных безопасТностью идиотов с руками из задницы - полным-полно, кто бы в этом сомневался.
впрочем, как и методичек, написанных такими же, требующими немедленно скачать самую распоследнюю версию незнамочего.
"не завозят" вам потому,что покупатели rhel к таковым не относятся, ну, по крайней мере, в большинстве своем. У них совсем-совсем другие задачи.
Совместимость? Вы про SSLv2 и SSLv3, я полагаю?
При этом им не помешало выпилить некоторые шифры, могли бы это как то через конфиг сделать.
через конфиг это должны делать не они, а альтернативно-одаренные авторы софта, использующего библиотеку. Многие, между прочим, и сделали - лет этак десять назад.Но мы ж заботимся о пользователях с куриными мозгами (теперь эта "забота" просочилась и в мозги горе-разработчиков библиотек, которые вообще пользователь видеть не должен) - надо им все небезопасТное запретить, запретить, запретить!
Ну а чего вы хотите, разработчики openssl небось тоже давно в гей эреа проживают.
> ну кроме больных, считающих, что чем больше цифирка тем круче шифрование.
Даунята, которые никогда не обновляются, как раз не обновляются потому что не читают ченжлоги. И считают что раз они нихрена не знают что же поменялось в новой версии, то ничего и не поменялось. Просто проф некомпетентность.
>>Даунята, которые никогда не обновляютсяа смысл обновлять, если зависимый софт при этом не обновился? И собственно качество openssl гавёное, такой софт должен быть стабильным, и не инкрементить номерки версий еженедельно.
пс: работает - не трогай!
Это всё таки слишком сложно для них. По уму - выдачей предупреждений с последующим исправлением - этим должен заниматься менеджер пакетов, в котором должна быть отдельная функциональность в виде специализированной экспертной системы, которая сама фоново занимается поиском проблемных версий программ, библиотек и конфигов, тестирует безопасность машины. Слишком много всего в сети работает на всяких никсах, чтобы позволить себе не иметь такой важной и нужной вещи.
>>Это всё таки слишком сложно для них.Должно ли быть всё сложно? Я думал, человек стремится к простоте, промолчу про "ад зависимостей", кто-то с места крикнет про автоматизацию, так вот в ответ - автоматизация разве решает сложности? Что есть сложность? - задумайтесь!
> а вот поломать совместимость с чем-то,А что, в редхатах нельзя поставить рядом две разных версии одной библиотеки?
С каких пор релиз x.y.Z стал "значительным"? На Semantic Versioning совсем уже всем стало наплевать?
Уважаемый, смотрите на changelog, а не на цифирьки, что вы как хипстер, в самом деле.
А "циферьки" тогда зачем? Можно же тогда как хром с лисой каждый релиз мажорную версию менять. SM же и придуман чтобы циферьки были не просто так, а несли в себе смысл.
За смыслом в "цифирьках" это вам к нумерологам или хотя бы в ближайшую церковь. Единственная логика в номере версии -- чем больше число, тем свежее код. И то не всегда.
> За смыслом в "цифирьках" это вам к нумерологам или хотя бы в ближайшую церковь.И эти люди ещё пытаются что-то там критиковать... Куда катится опеннет.
Хотя, понятно куда.
Дружок, а тебя не смущает, что ты пробил дно дна опеннета?
Ведь твоя критика полностью подпадает под твою же критику.
Можно как с лисой, можно как не с лисой, кому как нравится. Не у вас же спрашивать как версию называть.А SemVer бесполезен. К прикладному софту он слабо применим, а для библиотек опирается на совместимость API, которой на деле не существует (про это хорошо рассказано в https://www.youtube.com/watch?v=tISy7EJQPzI), и игнорирует совместимость ABI.
Да ладно, бесполезен. Тех, кто не читал дрепперовское dsohowto -- всё равно разве что нашим турбинским set versioning'ом на подлёте шмалять, и то кто-то да пролетит...
> А SemVer бесполезен. К прикладному софту он слабо применимВот и выросло поколение Гарри Поттеров.
Сам ты бесполезен, Анон. Ломаете совместимость - выпускайте мажорную версию.
Поддержка ранее выпущенных мажорных "релизов" отдельный вопрос.
> Ломаете совместимость - выпускайте мажорную версию.Допустим, я реализую графический редактор и значительно переписал большую часть кода, добавил много новых функций и несколько новых форматов файлов. Должен ли я увеличить минорную версию лишь потому, что совместимость с предыдущей версией сохранена?
Допустим, я исправил уязвимость при чтении некоторых типов файлов, в результате чего на некоторые читавшиеся ранее файлы приложение теперь ругается (даже если в них уязвимости нет). Должен ли я увеличить мажорную версию лишь потому, что совместимость пострадала?
1. нет
2. нет
Это крайние случаи, которых стоит избегать с помощью грамотного планирования разработки.
Вот и вырасло поколение буратин-теоретиков. Что ж ты не пришёл во все проекты которые когда-нибудь могут сломать совместимость и не распланировал их грамотно чтобы этого не случилось?
> Что ж ты не пришёл во все проекты которые когда-нибудь могут сломать совместимость и не распланировал их грамотно.Анон, при всем уважении, ты задаёшь тупые вопросы.
В тех проектах, где я отвечал модель за разработки и версионирование, мне удавалось придерживаться SV без особых проблем. Проектов было много (20+), я этим занимался несколько лет.
Вопросы я не задаю, это раз. Твой тепличный опыт яйца выеденного не стоит, это два.
Уважаемый, бесполезно говорить с малолетками на серьезные темы, они же ничего не знают и пытаются играть в троллей.
Ты даже не удосужился пройти по ссылке. А ты пройди, много нового узнаешь. Совместимость - фикция, и для кого-то её может сломать даже незначительнфй багфикс не затрагивающий API.
Таки да, в подавляющем большинстве --- фикция. Характерный пример --- библиотеки происходящие от GNOME-команды.
К лисе (не знаю, как к хрому) SM не применим по простой причине - у лисы релиз не зависит от фич или багфиксов, а жёстко привязан к графику. Релиз каждые N недель, то есть, делается срез репозитория, обзывается бетой, неготовые фичи выключаются, отлавливаются баги.Что интересно, хающие лису не вспоминают про ядро Linux, которое точно так же релизиться примерно через равные промежутки времени, второе число в версии просто увеличивается на 1, а первое число отражает ощущение Линуса "ну, вроде уже пора" (поинтересуйтесь переходом 3.x -> 4.x").
патамучта она бинарно совместима с 1.1.0
чтобы "стало плевать", сначала надо семверу следовать. А - тут открытие - не каждое ПО следует семверу.
> чтобы "стало плевать", сначала надо семверу следовать.Ему следовать довольно проблематично. Должного покрытия тестами почти никогда нет, а метод пристального вглядывания --- ненадёжен.
> На Semantic Versioning совсем уже всем стало наплевать?Всем адекватным - да.
Semantic Versioning изначально разрабатывалось для версионирования АПИ. У некоторых, из-за того, что они используют его не по назначению (а например, для версионирования версий софта, для которого оно в большинстве случаев не подходит), это приводит к проблемам, с которыми они отважно борются (можете их багтрекер на гитхабе почитать ради интереса, а не только главную страницу сайта). Другие же, невзирая на моду, просто не пытаются колоть орехи микроскопом.
> (а например, для версионирования версий софта, для которого оно в большинстве случаев не подходит), это приводит к проблемамА можно реальные примеры вашего примера? Желательно со ссылками.
А то складывается впечатление, что у кого-то просто знания "матчасти" не хватает.
Буду рад открыть для себя что-то новое.
Там сверху ссылка на доклад. Не появляйся сдесь пока его целиком не посмотришь, пожалуйста.
С докладчиком не согласен. Тратить на тебя время тоже желание пропало.
Спасибо что честно признал свою неправоту.
> А можно реальные примеры вашего примера? Желательно со ссылками.Год-два назад я думал, что СемВер решит все мои проблемы, поэтому решил полазать по их багтрекеру. Многие тикеты содержат интересные обсуждения на тему версий и того, насколько СемВер может быть применим в тех или иных условиях. После прочтения всех открытых на тот момент тикетов сложилось общее впечатление о СемВере, однако искать конкретные цитаты сейчас мне некогда.
Если есть желание действительно разобраться в теме, то ОЧЕНЬ советую почитать их багтрекер. Все открытые задачи. Там не так много, за день можно управиться.
Из того, что могу сходу озвучить:
1. Нумерация СемВер основана на понятии совместимости, тогда как нумерация софта традиционно отталкивается от понятий функционала и/или объёма выполненных работ. Это ортогональные понятия.
В случае СемВер изменение версий имеет следующие значение:
- мажорная - изменён/добавлен функционал, пропала совместимость,
- минорная - добавлен функционал, сохранена совместимость,
- патч - функционал не изменён, сохранена совместимость.В случае софта изменение версий имеет значение (если число компонент версий вообще три):
- мажорная - перед обновлением пользователю рекомендуется тщательно протестировать, всё ли работает, как он ожидает (либо значительно поменялся функционал, либо были переписаны крупные куски кода),
- минорная - добавлен функционал, можно обновиться, если новый функционал нужен, крупных проблем после обновления не возникнет, так как код глобально не переписывался,
- патч - исправлены ошибки, необходимо обновиться, проблем при обновлении не возникнет.Можно притянуть за уши эти две шкалы, если считать "совместимостью" способность пользователя, работавшего со старой версией, быстро начать работать с новой. Но имхо совместимость - это больше технический, формальный термин, и всегда можно чётко сказать, совместима новая версия со старой или нет. А совместимость "функционала" с точки зрения пользователя оценить может быть сложно, это термин больше психологический, неформальный.
Но даже в этом случае появится несоответствие, когда незначительное изменение рушит "совместимость". Если изменение в софте, то любой адекватный разработчик не станет менять мажорную версию. Хотя по логике СемВер менять нужно именно её.
Мажорная версия в случае СемВер меняется ТОЛЬКО когда ломается совместимость. А в случае версионирования ПО мажорную версию можно менять, например, каждые пять лет просто чтоб продемонстрировать "взрослось" проекта.
Плюс с точки зрения софта, если для исправления мелкой ошибки пришлось значительно поменять какой-то интерфейс или workflow, то меняется патч-версия. Тогда как в случае СемВер, по логике, нужно было бы менять старшую цифру из-за несовместимых изменений.
2. СемВер плохо отражает процесс разработки ПО.
Например, сортировка пререлизных версий идёт по алфавиту. Нам просто повезло, что согласно алфавиту alpha < beta < pre < rc. Но добавьте сюда ещё какую-нибудь стадию, специфичную для вашего проекта, и очень вероятно, что она не впишется в такой порядок.
В СемВер нет пострелизных версий. Вы можете создать 1.0.0-rc.1, но после релиза создать 1.0.0-daily.1 вы не сможете, так как daily будет между beta и pre. Для ежедневных сборок приходится либо использовать 1.0.0+daily.1 (при том, что при сравнении версий метаданные могут игнорироваться), либо нужно угадать, какой будет следующая версия (1.0.1, 1.1.0 или 2.0.0) и дальше делать её пререлизы (1.0.1-daily.1, 1.0.1-daily.2, ...). Если при этом появится функциональное добавление, то после 1.0.1-daily.2 у вас уже будет 1.1.0-daily.1. Это вместо того, чтоб плодить 1.0.0-daily.N а в нужный момент сразу решить, как назвать новую версию.
Тот факт, что любой daily заведомо окажется старше любого beta и младше любого pre (официальная позиция СемВер), не позволяет строить схемы с daily-релизами, местно прерываемыми другими релизами. В СемВер нельзя объявить, что daily невозможно сравнивать с beta/pre.
При нумерации версий софта бывает удобно использовать только две цифры (1.2) или добавить четвёртую (1.2.0.240, например для обозначения номера билда). СемВер недостаточно гибок, чтобы позволить такое.
При создании версии 1.0.0 вы делаете 0.1.0, 0.2.0, 0.3.0... 1.0.0. Но для создания версии 2.0.0 у вас нет такого запаса по числам, приходится изголяться и делать 2.0.0-dev.1.0, 2.0.0-dev.2.0 и т.д. И это описано в самом СемВер, вместо того чтоб запретить всё, начинающееся с нуля, и форсировать схему с 1.0.0-dev.1.0.
Некоторые проекты являются "модификацией" основного проекта. Основной выпускает версию 1.2.3, а модификация патчит эту версию и делает 1.2.3.0. После нахождения ошибок в модификации, выпускается 1.2.3.1. После релиза 1.2.4 основного проекта выпускается модификация версии 1.2.4.0. Это, конечно, можно переложить на СемВер, но для автора "модификации" (да и для пользователей) такой способ выглядит более наглядным. Использовать версии типа 1.2.3-modified.1 нельзя, так как это считается пререлизной версией, то есть 1.2.3-modified.1 < 1.2.3. Использовать 1.2.3+modified.1 тоже нельзя, так как инструмент сравнения версий может игнорировать метаданные, так что может получиться 1.2.3+modified.1 = 1.2.3+modified.2.
И лично я вообще не понимаю, зачем им дефис. Почему бы не использовать точку: 2.0.0.dev.1.0, всё же понятно.
3. В багтрекере вообще периодически встречаются комментарии, что СемВер предназначен для разного рода АПИ, и ни для чего другого (правда, я не обращал внимания, комментарии ли это мейнтейнеров СемВера или нет). Если версия вашего софта можно рассматривать как АПИ, то СемВер применим. Но если вы, к примеру, провели масштабный рефакторинг, то ни для пользователя, ни с точки зрения совместимости ничего не поменялось. Однако вы в этом случае можете счесть приемлемым увеличить мажорную версию.
Огромное спасибо за такой развернутый ответ! Респект.> Если есть желание действительно разобраться в теме, то ОЧЕНЬ советую почитать их
> багтрекер. Все открытые задачи. Там не так много, за день можно управиться.ОК, спасибо за наводку.
> Из того, что могу сходу озвучить:
> 1. Нумерация СемВер основана на понятии совместимости, тогда как нумерация софта традиционно
> отталкивается от понятий функционала и/или объёма выполненных работ. Это ортогональные
> понятия.....
> Плюс с точки зрения софта, если для исправления мелкой ошибки пришлось значительно
> поменять какой-то интерфейс или workflow, то меняется патч-версия. Тогда как в
> случае СемВер, по логике, нужно было бы менять старшую цифру из-за
> несовместимых изменений.Ну, это можно по ситуации решать, я признаю, что буквально следовать SV очень трудно.
С другой стороны, если приходится значительно менять интерфейс - сложно назвать это "мелкой ошибкой". я бы чинил не ломая, что можно (patch-level), остальное добавил в known issues,
и новый мажорный релиз выпустил с учетом предыдущих косяков.> 2. СемВер плохо отражает процесс разработки ПО.
> Например, сортировка пререлизных версий идёт по алфавиту. Нам просто повезло, что согласно
> алфавиту alpha < beta < pre < rc. Но добавьте сюда
> ещё какую-нибудь стадию, специфичную для вашего проекта, и очень вероятно, что
> она не впишется в такой порядок.Честно говоря, не вижу в этом проблемы. Заказчик получает доступ к папке с релизами, а там вполне можно добиться вменяемой сортировки версий. Сами по себе "alpha < beta < pre < rc", такой себе канон, сильно зависит от внутренней модели разработки, "pre" - уже не помню, когда видел последний раз.
>[оверквотинг удален]
> 1.2.3, а модификация патчит эту версию и делает 1.2.3.0. После нахождения
> ошибок в модификации, выпускается 1.2.3.1. После релиза 1.2.4 основного проекта выпускается
> модификация версии 1.2.4.0. Это, конечно, можно переложить на СемВер, но для
> автора "модификации" (да и для пользователей) такой способ выглядит более наглядным.
> Использовать версии типа 1.2.3-modified.1 нельзя, так как это считается пререлизной версией,
> то есть 1.2.3-modified.1 < 1.2.3. Использовать 1.2.3+modified.1 тоже нельзя, так как
> инструмент сравнения версий может игнорировать метаданные, так что может получиться 1.2.3+modified.1
> = 1.2.3+modified.2.
> И лично я вообще не понимаю, зачем им дефис. Почему бы не
> использовать точку: 2.0.0.dev.1.0, всё же понятно.Имхо, все эти цифры, буквы, плюсы, минусы, точки и т.п. знаки препинания уже болше определяются политикой и совокупностью гайдлайнов дистрибутивов, для которых приложение собирается.
например версия может быть appname-1.2.RC1-ubuntu+master.build3455.2fbf9281
в ней есть major(1),minor(2),patchlevel(RC1-ubuntu+master.build3455.2fbf9281),
при этом patchlevel точно описывает: состояние, под какую ось, из какой ветки взят код, номер билда/хэш коммита/дату билда и т.п.> 3. В багтрекере вообще периодически встречаются комментарии, что СемВер предназначен для
> разного рода АПИ, и ни для чего другого (правда, я не
> обращал внимания, комментарии ли это мейнтейнеров СемВера или нет). Если версия
> вашего софта можно рассматривать как АПИ, то СемВер применим. Но если
> вы, к примеру, провели масштабный рефакторинг, то ни для пользователя, ни
> с точки зрения совместимости ничего не поменялось. Однако вы в этом
> случае можете счесть приемлемым увеличить мажорную версию.имхо, всё что угодно можно рассматривать как АПИ. :) Даже конституцию.
ну рефакторинг - отдельная тема, выпускать функционально такой же продукт (но внутренне переработанный!) особого смысла нет, должны быть новые фичи, чтобы пользователь захотел поставить новую версию.
> должны быть новые фичи, чтобы пользователь захотел поставить новую версию.Увеличение скорости работы, снижение потребления ресурсов, пересмотр кода с точки зрения безопасных методик - может считаться новыми фичами (в функционале ничего не поменялось)?
Ну, на практике такое встречается когда "проведен глубокий рефакторинг кода, снижено потребление памяти, улучшена стабильность приложения" - единственная фича нового релиза.
> при этом patchlevel точно описывает: состояние, под какую ось, из какой ветки взят код, номер билда/хэш коммита/дату билда и т.п.Во-первых, избыточно (ср.: хеш и ветка; хотя без репозитория, содержащего этот коммит --- бесполезно); во-вторых, недостаточно (ABI, компилятор, etc.); в-третьих, бесполезно (под какую ось,... номер билда, дату билда).
> С другой стороны, если приходится значительно менять интерфейс - сложно назвать это "мелкой ошибкой"Ситуации разные бывают. Представьте, что приложение работает через веб-сервис, а в том обнаружили проблему безопасности, немного изменили АПИ, и из-за этого пришлось поменять интерфейс приложения. Согласен, что ситуация нечастая, но по СемВер она адекватно не разруливается. Идеальная схема версионирования должна предоставлять удобные варианты для наиболее типичных случаев и быть достаточно гибкой, чтобы позволить реализовать почти любой (а в идеале любой) нетипичный случай.
> Заказчик получает доступ к папке с релизами, а там вполне можно добиться вменяемой сортировки версий.
Вменяемую сортировку придётся делать самим и, вероятно, она будет несовместима с СемВер.
> patchlevel(RC1-ubuntu+master.build3455.2fbf9281)
А вот и нет. У вас в одном поле patchlevel сразу несколько величин, влияющих на сравнение и сортировку версий: статус (RC), номер релиза (1 после RC), номер билда (3455). То есть в вашем случае у вас не major.minor.patchlevel, а major.minor.stage.release.build, то есть 5 величин. СемВер позволяет только три.
Я, кажется, понимаю, вы хотите сказать, что сама схема major.minor.patchlevel логична, и под неё, в принципе, можно подогнать любую другую с определёнными допущениями. Но суть СемВера в том, что схема именно такая, как они описывают, а не почти такая же. Ваш пример - это уже не СемВер, и библиотеки, заявляющие поддержку СемВер, с вашим примером работать не будут. И люди, "имеющие опыт" работы с СемВер, тоже не поймут, что есть что. И проблема не в дефисах/плюсах/точках.
> выпускать функционально такой же продукт (но внутренне переработанный!) особого смысла нет, должны быть новые фичи, чтобы пользователь захотел поставить новую версию.
Почему? После 5 лет развития была версия 1.19.6. Автор решил, что добавлять новый функционал лучше в форме плагинов (не с точки зрения пользователя, а с точки зрения реализации и архитектуры приложения), а это будет возможно только после рефакторинга и добавления схемы работы с плагинами. Он переписывает кучу кода, выпускает 2.0.0, и уже на её основе начинает пилить 2.1.0 с новым функционалом в форме плагинов. Пользователям, конечно, нет смысла обновляться до 2.0.0, но автору такой подход может быть проще, чем сразу писать плагины и в качестве 2.0.0 выкладывать версию уже с новым функционалом.
А в debian зарегистрировали баг на тему совместимости ABI — https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908567
это не несовместимость abi, это руки у авторов qt растут из ануса - сперва они требуют от библиотеки поддержки последней возможной в ней версии, вместо последней поддерживаемой собой, или уж не лезть кривыми руками куда не надо вообще, оставив все по-умолчанию, а потом, вдруг "ой, а она нам незнакома, мы не знаем что с этим делать".В abi ничего не изменилось, в api тоже - константа не превратилась вдруг в long double вместо int, функция не поменяла свое поведение.
> это не несовместимость abi, это руки у авторов qt растут из ануса
> - сперва они требуют от библиотеки поддержки последней возможной в ней
> версии, вместо последней поддерживаемой собой, или уж не лезть кривыми руками
> куда не надо вообще, оставив все по-умолчанию, а потом, вдруг "ой,
> а она нам незнакома, мы не знаем что с этим делать".
> В abi ничего не изменилось, в api тоже - константа не превратилась
> вдруг в long double вместо int, функция не поменяла свое поведение.Я всё это понимаю, но пользователю от этого не легче.
ну, следующие дятлы просто намертво залинкуются с libssl.so.1.1.0h, не используя при этом ни одной version-specific фичи (довольно, кстати, распространенный вид идиотизма, как и наоборот, непонимание как надо давать имена файлу, а как - soname) - и их только подменой линка вручную и удастся побороть - это ж не abi виноват.
Если дочитать переписку, то там есть и другие такие же...
"что-то я и не удивлен"