Как происходит процесс семантического версионирования (SemVer)

Процесс версионирования с использованием семантического версионирования (SemVer) предполагает использование определённого формата версий: MAJOR.MINOR.PATCH. Этот формат помогает разработчикам и пользователям быстро понять характер изменений и их влияние на совместимость.

Как происходит процесс семантического версионирования (SemVer)

1. Формат SemVer:

• MAJOR (модульные изменения): Изменяется, когда вносятся несовместимые изменения в публичные API или интерфейсы.
• MINOR (дополнение функциональности): Увеличивается, когда добавляются новые функции, которые не ломают существующий функционал.
• PATCH (исправление багов): Используется для исправления ошибок, которые не нарушают обратную совместимость.

Пример:
Если версия сервиса была 1.2.3, то:

• При изменении API или несовместимых изменениях она станет 2.0.0.
• При добавлении новых функций она станет 1.3.0.
• При исправлении ошибок версия станет 1.2.4.

2. Где фиксировать версию

package.json (для Node.js проектов): Для сервисов на JavaScript/TypeScript версии обычно фиксируются в файле package.json в поле "version":

{ "name": "service-a", "version": "1.2.3", "description": "API service", ... }

Файлы конфигурации других языков: Для других языков версии могут фиксироваться в:

• pom.xml для Java (Maven),
• composer.json для PHP (Composer),
• pyproject.toml или setup.py для Python (Poetry или setuptools).

3. Когда фиксировать версию

• При завершении фичи или исправления багов: Когда новая функциональность или исправление готово, перед выпуском новой версии (release) проекта фиксируется новая версия.
• При выпуске релиза: Версия фиксируется при подготовке к деплою или релизу, особенно если используется процесс автоматизированного CI/CD.
• При слиянии изменений в основную ветку: Если используется Git, версия может обновляться при слиянии изменений в основную ветку (main или master).

4. Как не забыть фиксировать версию

• Использование тегов Git: Для фиксации версии можно автоматически проставлять Git-теги. Это создаёт контрольные точки для каждой версии. Например:

git tag -a v1.2.3 -m "Release version 1.2.3" git push origin v1.2.3

• Автоматизация с помощью CI/CD:Настрой инструменты вроде GitHub Actions, GitLab CI или Jenkins, чтобы автоматически повышать версии и фиксировать их при каждом релизе.
  Используй инструменты для управления версиями, такие как standard-version или semantic-release, которые автоматически обновляют файл версий (package.json и другие) и создают теги в Git.
  
• Использование коммитов с указанием изменений: Придерживайся строгих правил оформления коммитов с описанием изменений:fix: для исправлений багов,
  feat: для добавления новой функциональности,
  BREAKING CHANGE: для обозначения несовместимых изменений.
  Это можно интегрировать с инструментами, чтобы автоматически определять, какое изменение произошло, и обновлять версию.

Автоматизация с помощью инструментов

standard-version:

• Позволяет автоматизировать управление версией и генерацию changelog на основе коммитов.
• Пример использования:

npm install --save-dev standard-version

Для выпуска новой версии запусти:

npm run release

Это обновит версию в package.json и создаст новую запись в changelog.

semantic-release:

• Инструмент для полной автоматизации выпуска новых версий.
• Он проверяет коммиты, определяет тип изменений (мажорное, минорное, патч) и автоматически выпускает новые версии.
• Пример настройки с использованием GitHub Actions:

name: Release on: push: branches: - main jobs: release: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v2 with: node-version: '14' - name: Install dependencies run: npm ci - name: Run semantic-release run: npx semantic-release

Заключение

1. Фиксировать версию нужно в файле проекта (например, package.json).
2. Версию стоит обновлять при добавлении новых фич, исправлении багов или изменении API.
3. Чтобы не забыть фиксировать версию, лучше использовать автоматизацию с помощью CI/CD и инструментов вроде semantic-release или standard-version.

Это позволит избежать ошибок с версионированием и упростит управление проектами.