Существует ли эквивалентная схема Semantic Versioning для программного обеспечения, отличного от API?

Мне очень нравится схема Semantic Versioning, но это действительно имеет смысл для API, поскольку основное внимание уделяется нарушению изменений и обратной совместимости. Для не-API, например. программное обеспечение конечного пользователя, многие из правил больше не имеют смысла. Например, сама концепция обратной совместимости на самом деле ничего не значит; пользователь испытывает новые функции или их нет, меньше ошибок или нет, и т.д. Тем не менее я получал бы четкую схему для версии xyz, которая следует за духом Semantic Versioning, чтобы пользователи могли иметь представление о том, чего ожидать от номеров новой версии, если они знакомы со схемой.

Я пробовал рисовать что-то вроде:

Bump z, если вы вносите внутренние изменения в код (например, исправления ошибок, рефакторинг), которые не меняют пользовательский интерфейс. Может включать новые "внутренние" функции.
Ударьте, добавляя функции, которые изменяют пользовательский интерфейс, помимо исправлений ошибок, к текущим функциям.
Bump x...???... радикально разные изменения в пользовательском опыте? Что радикально отличается?
Начальная альфа-разработка происходит как 0.0.z
Первая версия бета-тестирования установлена в 0.1.0 и остается равной 0.y.z
Первая версия пользователя установлена в 1.0.0

Другая идея состоит в том, чтобы сделать х-удары, когда удаляются функции, поскольку некоторые пользователи могут полагаться на них, но это может показаться неоправданным в некоторых случаях. (Скажите, что вы знаете всех пользователей, и все они хотят удалить очень незначительную функцию. Переход с 1.0 на 2.0 будет несколько противоречивым.)

Это более субъективно, чем Semantic Versioning, потому что гораздо проще объективно идентифицировать обратные совместимые функции и нарушать функции API. Существуют ли какие-либо "стандартизированные" схемы управления версиями, которые я могу исследовать для получения дополнительных указаний?

Ответ 1

Я искал что-то подобное себе, но не нашел ничего "официального". Здесь, как я делал свою версию, нумеруя в последнее время, хотя.

Учитывая x.y.z

x= Приращение при каждом перепроектировании пользователя. Например, вы перестраиваете вещи на основном интерфейсе, как это делали Microsoft с Office 2003 по сравнению с 2007 годом. Если ваше приложение хранит пользовательские файлы или настройки, этот номер также должен увеличиваться, если изменения не будут обратно совместимы со старым файлы или настройки.
y= В основном увеличивается каждый раз, когда вы добавляете новую новую подпрограмму/функцию. Обычно такие вещи, как добавление нового элемента меню или кнопки, попадают в эту категорию, так как вам придется написать обратный вызов для обработки события клика на элемент меню или кнопку. Другим примером могут быть любые изменения кода, которые не делают заметной разницы с пользователем, но улучшают управляемость (например, вы, наконец, добрались до написания класса для управления вашим файлом настроек). Reset это число, если x увеличивается.
z= Приращение при каждом исправлении ошибки. Reset это число, если x или y увеличивается.

Примечание: Лично мне нравится думать, что если вы получите y в двузначных числах, пришло время рассмотреть редизайн пользовательский интерфейс, который приведет к увеличению x.

Ответ 1

Ответ 2