Версионирование

Одной из наиболее популярных и используемых схем управления версиями является семантическое версионирование. Этот метод позволяет разработчикам однозначно и просто сигнализировать пользователям о типе изменений, внесенных в программный продукт. Семантическое версионирование задействует трехуровневую цифровую схему, формата MAJOR.MINOR.PATCH, и предоставляет четкие правила для изменения каждого из этих уровней.

Как с ней работать

Система строится по формату MAJOR.MINOR.PATCH:

• Мажорная версия (MAJOR) увеличивается при внесении обратимо несовместимых изменений (например, удаление функций).
• Минорная версия (MINOR) увеличивается при добавлении нового функционала, не нарушая совместимость.
• Патч (PATCH) увеличивается при исправлении багов, не влияя на совместимость.
• При инкременте мажорной версии, сбрасываются минорная и патч версии. При инкременте минорной, сбрасывается только патч.

Что версионировать

Начнем с версионирования библиотек компонентов. Например, у вас две библиотеки: с мобильными компонентами и веб-компонентами. Ожидаемый результат хранится в Фигме, а фактический — в коде и библиотеки синхронизированы.

В таком случае, лучше сделать версионирование сквозным, где версия библиотеки в коде совпадает с версией библиотеки в Фигме. Можно версионировать библиотеку в целом и компоненты в частности, но хранить версии компонентов лучше только в коде, чтобы не обновлять версию вручную в Фигме.

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

Отдайте историю с версионированием на откуп разработке. Как только они выпускают версию, обновляйте ее у себя. Даже если это был технический релиз.

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

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

В этом случае отказывайтесь от разработки и ведите свое версионирование. Всякий раз, когда вносите изменения в документацию, дорабатываете движок сборщика, оптимизируете SEO или делаете любое другое изменение — повышайте версию.

Где хранить описание релизов

Можно хранить в Github в разделе Releases:

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

А можно прямо на сайте на отдельной странице, например на главной: