Semantic Versioning « Сайт по фигме, но автор отношения к ним не имеет! Not affiliated with Figma
Это не официальный сайт Figma / This is not the official site of Figma

Semantic VersioningSemantic Versioning

установить плагин для Фигмы Semantic Versioning

Плагин Semantic Versioning упрощает семантическое управление версиями для истории Фигмы без внешних зависимостей и использования через API.

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

Номер версии может использоваться для обозначения ожидаемых внутренних работ, вызванных текущими изменениями дизайна.

Этот плагин не имеет внешних зависимостей, информация о версии сохраняется в текущем документе.

Имейте в виду, что значение слова «backend» сильно зависит от настройки проекта. В прогрессивном веб-приложении «backend» обычно является внешней реализацией, тогда как backend на классической серверной веб-странице будет фактической реализацией веб-приложения на стороне сервера.

Как использовать этот плагин?

  1. Выберите одну или несколько точек истории и запустите плагин;
  2. Если выбрать несколько точек, получите список выбранных точек с их текущим статусом версии, считанным из внутренних данных плагина;
  3. Если выберете одну точку, получите интерфейс для изменения текущей версии этогточки в соответствии с реализованным рабочим процессом версии;

Как использовать рабочий процесс версии?

Номер версии состоит из трех-четырех числовых частей:

  • Rfc-часть в скобках не является обязательной и зависит от настройки «requests for comments».
  • Предполагается, что числа только увеличиваются. Цель предоставления номеров версий — разрешить автоматическую проверку зависимостей зависимыми системами.

MAJOR

Увеличение номера MAJOR означает обратное несовместимое изменение вашего дизайна.

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

Распространение этого изменения, скорее всего, нарушит работу backend-реализации. Вы сообщаете об этом, увеличивая номер основной версии на единицу, фактически говоря, что это обратно несовместимое изменение. И ожидаете, что это нарушит текущую реализацию.

MINOR

Увеличение номера MINOR означает обратно совместимое изменение вашего дизайна, обычно путем добавления функции.

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

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

PATCH

Увеличение числа выпусков PATCH означает простое исправление вашего проекта, не требующее какой-либо внутренней работы.

Допустим, вы настроили некоторые цвета или получили уведомление о том, что функция адаптивности не работает должным образом. Исправляя это, вы исправляете преднамеренную реализацию текущего проекта.

Используя номер версии PATCH, вы сообщаете, что во внутреннем интерфейсе вашего проекта нет изменений, и он не потребует никаких внутренних изменений.

RFC

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

Рабочий процесс Rfc добавляет к версии метку -rfc.1, отражающую текущую итерацию в процессе утверждения.

Допустим, вы делаете первый черновик формы, так как это незначительное изменение, вы решили добавить незначительное изменение, и, поскольку у вас включен рабочий процесс rfc, у вас есть только незначительный вариант выпуска (учитывая, что ваша текущая версия 1.0.0 ) — 1.1.0-rfc.1. Это сообщает, что вы подготовили первую версию предполагаемого незначительного изменения.

Затем ваша команда обсуждает черновик и дает вам обратную связь, требующую внесения изменений. После этих изменений вы увеличиваете номер Rfc, что приводит к 1.1.0-rfc.2. После еще одного обсуждения с вашей командой все в порядке с изменениями, и вы выпускаете дизайн до версии 1.1.0.

Как использовать настройки?

Настройки сохраняются для каждого документа. Тем не менее, придется настроить параметры один раз для каждого документа.

Используйте «request for comments»

Отметка этого параметра включает «pre-release» путь для управления версиями, который добавляет счетчик -rfc.<> к версии.

Использование этой функции позволяет помечать изменения как «proposal» в зависимости от рабочего процесса, в который встроена проектная работа.

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

Используйте приложение версии в именах истории

Установка этого параметра включает версии с префиксом @ для названия точки. Когда вы сохраняете версию, к названию точки добавляется символ @ (если он еще не существует), а к имени добавляется сохраненная версия.

Эта функция также добавляет в пользовательский интерфейс еще два параметра версии «From Appendix» и «To Appendix» (если версия приложения и внутренняя версия этой точки различаются), что позволяет вам, например, установить или удалить версию вручную. Пожалуйста, имейте в виду, что версии 0.x не поддерживаются этим плагином.

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

API

Целью этого интерфейса является предоставление внешнего доступа к сохраненному номеру версии (и, возможно, будущим свойствам).

В настоящее время все соответствующие данные хранятся как «shared plugin data», чтобы другие плагины могли использовать эти данные. Все следующие описанные поля являются частью стабильного API этого плагина и должны быть безопасными для использования.

Ключ sharedPluginData, используемый этим плагином, называется:

com.github.florianb.figma_semantic_versioning

Используйте его для доступа к свойствам плагина узла либо через Figma Plugin API, либо через Figma Rest API.

Разработчик: Florian Neumann

Плагины из той же категории