как семантическое управление версиями применяется к программам без API

На http://semver.org/, который, по моему мнению, является наиболее широко используемым соглашением при версионировании, рекомендуется увеличивать основной номер версии, когда вводится изменение, которое нарушает / модифицирует API.

Есть два связанных сценария, которые я не вижу, как применять это руководство:

1. Что если мой код не предлагает API? Как мне сделать версию моего кода?
2. Что если мой код начнет предлагать API на поздней стадии его разработки?

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

• У библиотеки программирования или веб-службы есть API.
• Потребительское программное обеспечение может иметь графический интерфейс.
• Программы командной строки имеют набор переключателей и опций.
• Файлы конфигурации также являются пользовательским интерфейсом.

Используя пример потребительского программного обеспечения, такого как текстовый процессор:

• Увеличивайте номер патча, когда вы отправляете исправление ошибки, например: « исправлена ​​ошибка, когда приложение всегда вылетает в 00:00 вечера по вторникам ».
• Увеличьте младший номер версии при добавлении новой функции, например: « добавлена ​​поддержка подчеркнутого текста ».
• Увеличьте основную версию, если вы существенно измените пользовательский интерфейс, или перепишите все внутренние компоненты. Например: « Панели инструментов используют слишком много экрана. Пользовательский интерфейс теперь предоставляется только с помощью сенсорных жестов »- такое изменение может нарушить существующие рабочие процессы.

Однако многие проблемы, которые пытается решить Semver, не существуют за пределами области управления зависимостями. В потребительских приложениях версия - это не только версия, но и маркетинговый актив.

• Firefox и Chrome выпускают новые версии сравнительно часто и увеличивают номер своей основной версии при каждом выпуске. Это приводит к смехотворно высоким номерам версий (сейчас им по 30). Браузер с более высоким номером версии должен быть просто лучше, чем браузер с более низким номером версии, верно?

• Основной номер версии операционной системы Apple OS X стал частью названия (X - 10 в римских цифрах), что делает младший номер версии эффективным номером основной версии.

• В операционной системе Ubuntu используется схема управления версиями year.month.patchlevel. Это позволяет легко помнить, сколько лет вашей ОС, но гораздо сложнее выяснить, какие версии совместимы, и как долго длится поддержка каждой версии.

• Ядро Linux изменило номер версии с 2.6.39 до 3.0.0, потому что оно 39становилось немного большим, и в ознаменование 20-летия Linux.

• Легендарная система набора текста TeX Дональда Кнута использует номер версии, который, начиная с версии 3, сходится к π, добавляя еще одну цифру в каждом выпуске: 3.14159265…. Это показывает, как система приближается к совершенству. Аналогично, система Metafont сходится к e : 2.7182818….

Таким образом, Semver плохо обслуживает многие приложения. Выберите схему управления версиями, которая подходит вашим пользователям (независимо от того, являются ли эти пользователи коллегами-программистами или потребителями), и придерживайтесь ее.