Случайно наткнулся на вот такую штуку: Semantic Versioning. Это описание "стандарта" на систему нумерации версий программного компонента. С переводом на несколько языков, в том числе и на русский (перевод я не читал, о его качестве судить не берусь).
Собственно, там описывается очень старая идея. Которая до этого описывалась разными авторами под разным соусом, в том числе и мной. Если никогда не приходилось слышать про идею, стоящую за системой нумерации версий из трех буквцифр, то бишь X.Y.N, то имеет смысл прочитать этот стандарт. Тем более, что там прошли достаточно далеко в плане формализации.
Сам же я пришел к выводу, что система из четырех чисел в номере версии удобнее. А если кому-то нужно пять или шесть чисел, то это так же имеет право на жизнь.
Самое старшее число в номере -- это номер поколения библиотеки/компонента. Номера поколений показывают настолько большие различия в API и/или принципах работы компонента, что в рамках одного проекта появляется возможность задействовать сразу два или более поколения одного и того же компонента. Например, в моей практике были случаи, когда в больших проектах мирно соиспользовались cls-2 и cls-3, oess-1 и oess-2, so-4 и so-5.
Следующее число -- это мажорный номер версии. Он описывает совместимость версий компонента внутри поколения. Например, so-5.5 не вполне совместим с so-5.4 и для перехода с 5.4 на 5.5 нужно будет приложить некоторые усилия.
Следующее число -- это минорный номер версии. Его изменение говорит о том, что в компонент вносились какие-то изменения/модификации, но совместимость с предыдущими версиями сохранилась. Так, переход с 5.4.0 к 5.4.1 должен быть безболезненным. В теории :)
Следующее число -- это номер патча. Его изменение говорит о том, что в компоненте исправлена какая-то проблема, но никаких несовместимостей это не породило. Т.е. номера 5.4.0.1 и 5.4.0.2 говорят об исправлении багов в версии 5.4.0, но не о внесении в 5.4.0 каких-то новых возможностей.
Вот так и формируется система generation.major.minor.patch.
Вполне могу допустить, что кому-то четырех чисел будем мало и он захочет добавить что-то еще. Например, номер ревизии в репозитории и номер-билда или дату-время-сборки. Чтобы получилось что-то вроде 5.4.0.1.865.201409112315.
Почему трех чисел мне недостаточно? Потому, что компоненты бывают разных размеров, с разным количеством внешних зависимостей, разной степени удачности и востребованности. Когда компонент маленький и ни от кого не зависит, трех чисел в версии вполне может хватить. Но сплошь и рядом встречаются другие варианты.
Например, сделана версия 5.4.0, она оказалась удачной и начала использоваться в десятке других компонентов. После чего появилась версия 5.5.0. Но переход на нее не происходит в одночасье. Какое-то время версии 5.4.0 и 5.5.0 вынуждены сосуществовать и разработчикам нужно править баги, откуда появляются 5.4.0.1, 5.4.0.2 и т.д.
Отдельный вопрос -- это изменение зависимостей компонента. Например, в версии 5.4.0 использовалась библиотека LockFreeDataStructs-1.5.0, затем вышла улучшенная версия LockFreeDataStructs-1.6.0. В результате перевода компонента на нее появилась версия 5.4.1 (ведь нужно как-то в номере версии отразить изменение зависимостей?). Однако, при попытке задействовать 5.4.1 в каком-то из проектов выяснилось, что LockFreeDataStructs-1.6.0 не дружит другой сторонней библиотекой FineGrainedParallelism-2.30.46.15. И для этого проекта пока не остается ничего другого, как оставаться на 5.4.0.2.
Между тем в 5.4.1 находятся новые баги, которые приводят к появлению версий 5.4.1.1, 5.4.1.2. И, весьма вероятно, такие же баги находятся и в 5.4.0, что ведет к 5.4.0.3, 5.4.0.4 и т.д. При этом параллельно живет и развивается версия 5.5.0, в которой так же исправляются баги и появляются версии 5.5.0.1, 5.5.0.2, ...
PS. Я слишком долго работал на одном месте и имел возможность наблюдать за эволюцией проектов и их составляющих в течении многих лет. Например, тот же SObjectizer на моих глазах развивается уже почти двадцать лет. Так что все вышеописанные заморочки с нумерацией версий я считаю оправданными. Но вовсе не обязательно разделять мое мнение. Особенно во времена, когда всякую херню можно закинуть на github, а там она начнет жить своей собственной жизнью (или тихо сдохнет, что, по идее, должно случаться гораздо чаще).
Комментариев нет:
Отправить комментарий