Перейти к содержимому
NEO

Версионирование согласно спецификации SemVer 2.0.0

Рекомендуемые сообщения

Короткое предисловие от @eu_tomat для случайно попавших в эту тему читателей.

Эта тема выглядит странновато, потому что она отпочковалась как оффтоп из другой.

Надеюсь, ссылка на исходную тему прояснит контекст обсуждения.

 

 

Немного оффтопа, но по спецификации semver, версия 0.0.3 имеет право на существование?

Или мы не используем semver.

Изменено пользователем eu_tomat
добавил предисловие

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, NEO сказал:

Немного оффтопа, но по спецификации semver, версия 0.0.3 имеет право на существование?

По спецификации 2.0.0 семантического версионирования, ни одна из версий 0.0.1, 0.0.2 или 0.0.3 не имеют право на существование. По данной спецификации версии следовало бы именовать 1.0.0, 1.0.1 и 1.0.2

Но я узнал о стандарте semver уже после выпуска 0.0.2, потому решил не переписывать номера версий, ибо это потребовало бы модификации исходников уже "выпущенных" версий (для соответствия тега релиза и текста в самой программе) и их последующего перевыпуска с удалением неверных тегов.

Как итог: я собираюсь продолжить именовать ПАТ-релизы 0.0.X, ПБТ-релизы - 0.X.Y, а пост-релизные версии OCLIDE можно уже будет именовать по semver'у.

Изменено пользователем VladG24_YT
Конкретизировал к чему относятся ПАТ, ПБТ и пост-релизы

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, VladG24_YT сказал:

По спецификации 2.0.0 семантического версионирования, ни одна из версий 0.0.1, 0.0.2 или 0.0.3 не имеют право на существование.

А какому пункту спецификации это противоречит?

 

https://semver.org/lang/ru/

 

Нулевые версии допустимы:

Цитата

Мажорная версия ноль (0.y.z) предназначена для начальной разработки. Всё может измениться в любой момент. Публичный API не должен рассматриваться как стабильный.

 

Есть пункт, запрещающий ведущие нули в числах:

Цитата

Обычный номер версии ДОЛЖЕН иметь формат X.Y.Z, где X, Y и Z — неотрицательные целые числа и НЕ ДОЛЖНЫ начинаться с нуля. X — мажорная версия, Y — минорная версия и Z — патч-версия. Каждый элемент ДОЛЖЕН увеличиваться численно. Например: 1.9.0 ->1.10.0 -> 1.11.0.

Эту формулировку можно понять так, будто бы запрещёны и нулевые числа, но приведённый пример опровергает это.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
27 минут назад, eu_tomat сказал:

А какому пункту спецификации это противоречит?

 

https://semver.org/lang/ru/

 

Нулевые версии допустимы:

 

Есть пункт, запрещающий ведущие нули в числах:

Эту формулировку можно понять так, будто бы запрещёны и нулевые числа, но приведённый пример опровергает это.

Предлагаю перенести данное обсуждение в другую тему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, NEO сказал:

Предлагаю перенести данное обсуждение в другую тему.

Поддерживаю.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, eu_tomat сказал:

А какому пункту спецификации это противоречит?

Второму пункту.

 

Согласно абзацу перед пунктами спецификации:

Цитата

Слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT), «ОБЯЗАТЕЛЬНО» (REQUIRED), «СЛЕДУЕТ» (SHOULD), «НЕ СЛЕДУЕТ» (SHOULD NOT), «РЕКОМЕНДОВАННЫЙ» (RECOMMENDED), «МОЖЕТ» (MAY) и «НЕОБЯЗАТЕЛЬНЫЙ» (OPTIONAL) в этом документе должны быть интерпретированы в соответствии с RFC 2119.


Тем временем RFC 2119 гласит:

Цитата

1. MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
...
4. SHOULD NOT

This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.


Во втором пункте спецификации использован термин MUST, а в четвёртом пункте используется SHOULD NOT:

Цитата

 

2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

...

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

 


Так как в данном случае способ версионирования с нулевой мажорной версией можно назвать полезным лишь субъективно, а объективного взвешивания всех "за" и "против" использования такого способа не проводилось, то можно смело заявить что четвёртый пункт спецификации SemVer не переопределяет и не опровергает второй.

Единственным возможным верным (с точки зрения RFC 2119) использованием нулевой мажорной версии SemVer в данном проекте (OCLIDE) я вижу лишь вариант, при котором в публичный доступ так же выкладывались бы INDEV-версии за период с Марта 2020 (коммит 9894b7a) до Января 2021 (коммит 3dc00f0, включительно).

Изменено пользователем VladG24_YT
Добавил ссылки на оригинальную спецификацию SemVer и спецификацию RFC 2119

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
8 минут назад, VladG24_YT сказал:

Так как в данном случае способ версионирования с нулевой мажорной версией можно назвать полезным лишь субъективно, а объективного взвешивания всех "за" и "против" использования такого способа не проводилось, то можно смело заявить что четвёртый пункт спецификации SemVer не переопределяет второй.

Здесь закралась ошибка. Объективно запрета нет. Субъективно же как раз взвешивание "за" и "против". Также, говоря о пользе, имеет смысл уточнять, для кого именно полезно, для достижения какой цели, в какой ситуации. Также изначальный вопрос был "что полезно, и что неполезно", а что имеет право на существование.

2 часа назад, NEO сказал:

по спецификации semver, версия 0.0.3 имеет право на существование?

FAQ спецификации semver содержит рекомендацию начинать разработку с версии 0.1.0, но она необязательна.

 

17 минут назад, VladG24_YT сказал:

Единственным возможным верным (с точки зрения RFC 2119) использованием нулевой мажорной версии SemVer в данном проекте (OCLIDE) я вижу лишь вариант, при котором в публичный доступ так же выкладывались бы INDEV-версии за период с Марта 2020 (коммит 9894b7a) до Января 2021 (коммит 3dc00f0, включительно).

Тут вопрос не в публичности репозитория, а в том, какую из версий разработчик посчитает достойной назвать релизом. Нулевая мажорная версия обеспечивает разработчику максимальную свободу, не связывая его обязательствами по поддержке существующего API или формата данных.

 

Кстати, какой API предоставляет твоя OCLIDE и с какими версиями API эмуляторов совместима?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, eu_tomat сказал:

Тут вопрос не в публичности репозитория, а в том, какую из версий разработчик посчитает достойной назвать релизом. Нулевая мажорная версия обеспечивает разработчику максимальную свободу, не связывая его обязательствами по поддержке существующего API или формата данных.

Хм... Тогда получается, что в принципе такое версионирование по SemVer'у вполне может существовать, окей. Но тем не менее я не смогу применить SymVer к "релизам" OCLIDE по двум причинам:

  1. Я не считаю, что текущее состояние программы можно выводить на релиз. Слишком много мелких косяков.
  2. Меня не устраивает "максимальная свобода" нулевой мажорной версии, ибо мне хочется всё-таки связать себя обязательствами доведения продукта до относительной завершённости с целью недопущения повторения истории со всякими долгостроями, которые потом просто закрываются.
1 час назад, eu_tomat сказал:

Кстати, какой API предоставляет твоя OCLIDE и с какими версиями API эмуляторов совместима?

Касательно эмуляторов - версия 0.0.3 точно совместима с OCEmu от gamax92, коммит bcb7a1ad6a370e3254afa9f7d483307e811ee5c6. Тесты с другими билдами не проводил.

 

У OCLIDE нет чётко сформулированного API. Но в принципе версию 0.0.3 можно представить как набор следующих интерфейсов:

  • Графический интерфейс, созданный через библиотеку Swing из пакета AdoptOpenJDK 8.0.265.01.
  • Редактор кода на Java 8 с применением RSyntaxTextArea 3.1.1, AutoComplete 3.1.0 и SpellChecker 3.1.0 за авторством bobbylight.
  • Конфигуратор для OCEmu (без спецификации версии, так как он не поставляется вне OCLIDE), совместимый с вышеупомянутым билдом OCEmu.
  • Вспомогательная утилита UUIDGenerator, использующая библиотеку "uuid" OpenOS 1.7 для генерации UUID компонентов для машин OCEmu.
  • Набор классов в пакете ru.VladTheMountain.oclide.configurator.ocemu.component, обеспечивающих взаимодействие конфигуратора и редактора.
Изменено пользователем VladG24_YT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
9 минут назад, VladG24_YT сказал:

Но тем не менее я не смогу применить SymVer к "релизам" OCLIDE по двум причинам:

  1. Я не считаю, что текущее состояние программы можно выводить на релиз. Слишком много мелких косяков.
  2. Меня не устраивает "максимальная свобода" нулевой мажорной версии, ибо мне хочется всё-таки связать себя обязательствами доведения продукта до относительной завершённости с целью недопущения повторения истории со всякими долгостроями, которые потом просто закрываются.

Эти-то причины как раз и не мешают применять semver. Можешь смело переходить на 1.0.0. То была рекомендация а не требование. Semver не мешает начать хоть с версии 100500.0.0 или скакнуть на неё с 0.0.1. Желательно иметь разумное обоснование таких скачков, но это не требование semver.

 

17 минут назад, VladG24_YT сказал:

Графический интерфейс

С GUI сложнее. Semver описывает систему версионирования применительно к API. В случае графических интерфейсов появляется широкое поле для субъективных интерпретаций. По идее, мажорная версия должна быть увеличена при глобальном изменении интерфейса. Минорная версия увеличивается при добавлении нового функционала без больших изменений интерфейса. А патч-версия увеличивается при баг-фиксах. Но всё это относительно.

 

Если я переместил кнопку на 100 пикселей выше, это баг-фикс, или изменение интерфейса? С точки зрения пользователя это может быть баг-фиксом. А с точки зрения другого пользователя или какого-нибудь автокликера это может быть нарушением совместимости.

 

А если я добавил так много мелкого функционала в очередную минорную версию, что графический интерфейс стал мало похож на прежний, то стоит ли считать это изменение глобальным и увеличивать мажорную версию?

 

Тут чёткий рецепт вряд ли возможен, и в каждой команде разработчиков могут быть свои предпочтения в версионировании.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в тему...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...