Политика развития¶
Сообщение о проблемах безопасности¶
Внимание
Если вы считаете, что обнаружили проблему безопасности в нашем коде, пожалуйста, сообщите о ней частным образом, написав нам по адресу 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
Новые строки должны быть добавлены в начало списка.