Здравствуйте.
Вот допустим, есть у меня библиотека. В свойствах проекта значение версии установлено 1.0.0. Я так понимаю, инкрементить надо вручную? Сейчас хочу допилить новую функцию и инкрементнуть до 1.0.1. Чтобы в коммите другого проекта написать, что нужна версия библиотеки 1.0.1.
И вот тут непонятка. Запиливаю новую функцию и делаю коммит “Запилил новую фичу”. Но номер версии остался 1.0.0. Его что отдельным коммитом потом инкрементить?
Или другой пример. У меня версия библиотеки 1.1.5 и я пилю 1.2.0. При этом, я кардинально что-то меняю. Но в промежуточных коммитах так и висит версия 1.1.5. Если такой коммит скомпилировать и подключить к проекту, которому нужна 1.1.5 - работать не будет.
Собственно, вопрос в том, что делать с нумерацией в промежуточных коммитах и что обычно делают?
Например здесь
в первых комминтах после каждого релиза я просто убираю строчку с номером версии. А на внутреннюю нумерацию версий в свойствах проекта я изначально забил.
Можно, конечно, просто забить на нумерацию. Но потом будет сложно разобраться, какой коммит библиотеки какому коммиту проекта нужен (когда захочется скомпилить старые версии).
Что считать несовместимыми изменениями? Несовместимыми с чем?
Как можно добавить новый функционал, сохранив при этом обратную совместимость? Добавление нового функционала подразумевает добавление новых и, скорее всего, модификацию старых публичных методов. А это уже потеря совместимости.
Не редко при багфксах приходится что-то делать с сигнатурами публичных методов, что тоже ломает совместимость.
То есть, часто бывает так, что при добавлении нового функционала приходится допиливать кучу уже существующих публичных методов (или наоборот, сделать их непубличными за ненадобностью). Тогда получается, что почти любое допиливание кода так или иначе ломает совместимость и приводит к накрутке X. Но это же бред
Да, текст по ссылке дальше шапки я тоже читал. Но про эти моменты там, всё-равно, не сильно понятно. Я могу хоть раз в неделю новый функционал запиливать. Но тогда X улетит в стратосферу из-за того, что публичные методы будут постоянно как-то меняться Этот момент крайне непонятен.
Кажется, что в номере версии недостаёт четвёртого числа. Тогда было бы норм. Но почти везде версию обозначают тремя числами и их хватает.
Это ж больше про библиотеки и API, а не приложения. Их надо продумывать так, чтоб не менять часто.
Чтобы у пользователя библиотеки не сломалось что-нибудь при обновлении с 1.0 на 1.1.
Речь именно про API для внешнего мира, а не просто какие-то внутренние не приватные методы (в С# есть internal для них, в других языках часто просто соглашения о наименовании или документация метода).
Так я про publicи и говорю. Я знаю, что есть internal.
Но если мы пишем, например, обёртку для какого-то API, которое само часто меняется, то по-любому придётся часто менять публичные методы. Или когда библиотека находится на ранней стадии разработки. Нереально заранее продумать, что и как должно быть.
Например. API Twitch. У них в новом официальном API уже много лет не работает пара нужных фишек. Одну из них они сами выпилили, а вторая есть в официальных доках, но не работает. Им об этом регулярно кто-то пишет (даже я писал), но они ничего с этим не делают. Их админ говорит, что у него работает. Возможно, оно просто не из всех стран работает (почему-то зачем-то)
По-этому, приходится искать и юзать недокументированное API
Это я видел. Но тут не сказано, что накручивать при изменении публичных методов / свойств / конструкторов.
Ну так недокументированное на то и недокументированное. Тут семантические версии не особо имеют смысл, оно может просто перестать работать и какая-то версия внезапно станет бесполезной.
Это я знаю. Ну а что в итоге? Правильно ли я понял, что X накручивается в том случае, если меняется что-то публичное и ломает совместимость? А если новое публичное просто добавляется, не меняя старое, то Y?
Допустим, у нас библиотека.
