1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/antv-X6

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.zh-CN.md 8.7 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 02.12.2024 11:08 8fca3e8

Правила внесения вклада

Если у вас есть какие-либо вопросы, пожалуйста, отправьте issue или PR!

Отправка issue

  • Определите тип issue.
  • Избегайте отправки повторяющихся issue, перед отправкой проведите поиск существующих issue.
  • Включите в теги, заголовок или содержание ясное намерение.

После этого ответственный за AntV подтвердит намерение issue, обновит соответствующие теги, свяжет с milestone и назначит разработчика.

Внесение кода

Отправка Pull Request

Если у вас есть права разработчика в репозитории и вы хотите внести код, вы можете создать ветку, внести изменения в код и отправить PR. Команда разработчиков AntV рассмотрит код и объединит его в основную ветку.

# Сначала создайте ветку для разработки, имя ветки должно иметь смысл, избегайте использования update, tmp и т. д.
$ git checkout -b branch-name

# После завершения разработки запустите тесты, чтобы убедиться, что они проходят, при необходимости добавьте или измените тестовые примеры
$ npm test

# После успешного прохождения тестов отправьте код, следуйте инструкциям ниже для сообщения

$ git add . # git add -u для удаления файлов
$ git commit -m "fix(role): role.use must xxx"
$ git push origin branch-name

После отправки вы можете создать Pull Request на x6.

Поскольку никто не может гарантировать, сколько времени пройдёт до того, как он вспомнит подробности, для удобства последующего отслеживания истории, пожалуйста, предоставьте следующую информацию при отправке MR:

  1. Требование (обычно связанное с issue или комментарием).
  2. Причина обновления (в отличие от issue, можно кратко описать, почему необходимо обработать).
  3. Тестовые точки фреймворка (можно связать с тестовыми файлами, подробное описание не требуется, достаточно ключевых точек).
  4. Точки внимания (для пользователей, могут отсутствовать, обычно это не совместимые обновления и т. п., требующие дополнительного уведомления).

Стиль кода

Ваш стиль кода должен пройти проверку eslint, вы можете запустить $ npm run lint для тестирования локально.

Правила оформления коммитов

Следуйте формату сообщений о коммитах, описанному в angular, чтобы история выглядела более чёткой и могла автоматически генерировать changelog.

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

(1) type

Тип фиксации включает следующие типы:

  • feat: новая функция
  • fix: исправление проблемы
  • docs: изменение документа
  • style: изменение стиля кода без влияния на логику кода
  • refactor: рефакторинг кода, теоретически не влияющий на существующие функции
  • perf: улучшение производительности
  • test: добавление или изменение тестовых примеров
  • chore: изменение инструментов (включая, но не ограничиваясь, документами, генерацией кода и т.д.)
  • deps: обновление зависимостей

(2) scope

Область изменения файла

(3) subject

Кратко опишите, что было сделано в этом коммите

(4) body

Дополните subject, если необходимо, объясните причины, цели и т.п., также можно не писать.

(5) footer

  • При наличии несовместимых изменений (Breaking Change) обязательно подробно опишите их здесь
  • Свяжите с соответствующими issue, например Closes #1, Closes #2, #3

Пример:

fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9

Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.

Document change on antvis/x6#12

Closes #392

BREAKING CHANGE:

  Breaks foo.bar api, foo.baz should be used instead

Для получения дополнительной информации см. документацию.

Управление релизами

X6 использует семантический номер версии semver для управления выпусками.

Ветвь master является текущей стабильной версией выпуска.

  • Непосредственно из master создайте ветвь разработки.
  • Все устаревшие API должны быть отмечены как deprecated в текущей стабильной версии, и должна быть обеспечена совместимость с новой версией до её выпуска.

Стратегия выпуска

В каждом крупном выпуске будет PM, который будет нести ответственность за различные этапы выпуска:

Подготовка:

  • Создание milestone, подтверждение связи с issues и назначение задач.

Перед выпуском:

  • Убедитесь, что все issues в текущем milestone закрыты или могут быть отложены, а также завершите тестирование производительности.
  • Создайте новый Release Proposal MR, следуя node CHANGELOG, напишите историю и исправьте связанные с версией документы.
  • Назначьте следующего PM для крупного выпуска.

Во время выпуска:

  • Сделайте резервную копию старой стабильной версии (master) в ветке с именем текущего большого выпуска (например, 1.x), и установите тег как {v}.x (v — текущая версия, например, 1.x).
  • Выпустите новую стабильную версию на npm и сообщите вышестоящей структуре о необходимости обновления.
  • Перед публикацией на npm, пожалуйста, прочитайте 『Как я публикую пакет npm』.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/antv-X6.git
git@api.gitlife.ru:oschina-mirror/antv-X6.git
oschina-mirror
antv-X6
antv-X6
master