Политика развития¶

Сообщение о проблемах безопасности¶

Внимание

Если вы считаете, что обнаружили проблему безопасности в нашем коде, пожалуйста, сообщите о ней частным образом, написав нам по адресу security@divio.com.

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

Обзор¶

Все исправления должны быть сделаны в виде запросов на исправление против develop на the GitHub repository. Патчи никогда не должны выкладываться напрямую.

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

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

Официальное утверждение¶

Формальное одобрение означает комментарии «OK to merge» после рассмотрения, по крайней мере, одним членом основной команды, обладающим опытом в соответствующих областях, исключая автора запроса на слияние.

Предложение и обсуждение существенных изменений¶

Новые возможности и изменения, несовместимые с предыдущими, должны быть предложены с помощью Discourse forum. Обсуждение должно происходить там до того, как будут сделаны какие-либо запросы на внесение изменений.

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

График выхода¶

Изменено в версии 3.7: django CMS 3.7 - это новый активный долгосрочный релиз.

С roadmap можно ознакомиться на нашем сайте.

Мы планируем релизы в соответствии с ключевыми принципами и целями. Поэтому вопросы в рамках основных этапов могут быть изменены.

django CMS Discourse forum служит местом сбора разработчиков. Мы представляем идеи и предложения до достижения целей дорожной карты.

django CMS 3.4, превзойденный 3.7, стал первым «LTS» («Long-Term Support») релизом приложения. Долговременная поддержка означает, что эта версия будет продолжать получать обновления безопасности и другие критические обновления в течение 24 месяцев после своего первого выпуска.

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

Филиалы¶

Изменено в версии 3.3: Ранее мы поддерживали ветвь master (теперь удалена) и набор ветвей support (теперь обрезаны и переименованы в release).

Изменено в версии 3.7: Упрощено описание ветвей релиза и добавлена дополнительная информация для releases и release/4.0.x. В целом, открыты PR против develop.

Мы поддерживаем несколько ответвлений на our GitHub repository:

develop: Целевая ветка по умолчанию для текущей разработки и новых запросов.
release/x.y.z - это последние выпущенные версии django CMS. Коммиты: взяты из develop и объединены в release/x.y.z, когда они подходят. Мы официально поддерживаем последнюю, самую высокую выпущенную версию и последнюю LTS (в настоящее время 3.7).
release/4.0.x является экспериментальной ветвью и не должна рассматриваться: как самая высокая из выпущенных версий.
releases размещает файл releases.json для указания наличия новых: версии django CMS при использовании djangocms-admin-style.

Пожалуйста, всегда открывайте PR против develop и указывайте, что они должны быть перенесены в последний релиз LTS, когда это необходимо. Более старые ветки больше не поддерживаются.

Обязательства¶

Добавлено в версии 3.3.

Сообщения об обязательствах¶

Коммерческие сообщения и их темы должны быть написаны в прошедшем времени, а не в настоящем, например:

Обновленная политика в отношении взносов.

Обновление политики филиалов для уточнения назначения филиалов разработки/релиза

Добавлена политика фиксации.

Добавлен журнал изменений.

Строки должны быть короткими и по возможности не превышать 72 символов.

Сквоширование коммитов¶

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

Например, нам не нужна история коммитов для того, что должно быть одним коммитом, который выглядит как (самый новый последний):

2dceb83 Updated contribution policies.
ffe5f2c Fixed spelling mistake in contribution policies.
29168da Fixed typo.
85d925c Updated commit policy based on feedback.

Три нижних коммита - это просто шум. Они не отражают развитие кодовой базы. Эти четыре коммита должны быть сведены в один, значимый, коммит:

85d925c Updated contribution policies.

Как сминать коммиты¶

В приведенном выше примере вы используете git rebase -i HEAD~4 (4 относится к количеству сжимаемых коммитов - настройте его по необходимости).

Это откроет файл git-rebase-todo (показывающий коммиты с последним новым):

pick 2dceb83 Updated contribution policies.
pick ffe5f2c Fixed spelling mistake in contribution policies.
pick 29168da Fixed typo.
pick 85d925c Updated commit policy based on feedback.

«Исправьте» последние три коммита, используя f так, чтобы они были сплюснуты в первый, а их сообщения о фиксации были отброшены:

pick 2dceb83 Updated contribution policies.
f ffe5f2c Fixed spelling mistake in contribution policies.
f 29168da Fixed typo.
f 85d925c Updated commit policy based on feedback.

Сохраните - и у вас останется один коммит, содержащий все изменения:

85d925c Updated contribution policies.

Просите о помощи, если столкнулись с трудностями!

Changelog¶

Добавлено в версии 3.3.

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

Каждая строка в журнале изменений должна начинаться с глагола в прошедшем времени, например:

* Added CMS_WIZARD_CONTENT_PLACEHOLDER setting
* Renamed the CMS_WIZARD_* settings to CMS_PAGE_WIZARD_*
* Deprecated the old-style wizard-related settings
* Improved handling of uninstalled apphooks
* Fixed an issue which could lead to an apphook without a slug
* Updated contribution policies documentation

Новые строки должны быть добавлены в начало списка.

Сообщество вкладчиков

Как внести свой вклад

Вернуться на верх