Development & community

django CMS is an open-source project, and relies on its community of users to keep getting better.

• Development of django CMS
• Contributing code
• Contributing documentation
• Contributing translations
• Code and project management
• Running and writing tests
• Code of Conduct

Community

You can join us online:

• in our IRC channel, #django-cms, on irc.freenode.net. If you don’t have an IRC client, you can join our IRC channel using the KiwiIRC web client, which works pretty well.
• on our django CMS users email list for general django CMS questions and discussion
• on our django CMS developers email list for discussions about the development of django CMS

You can also follow:

• the Travis Continuous Integration build reports
• the @djangocms Twitter account for general announcements

You don’t need to be an expert developer to make a valuable contribution - all you need is a little knowledge of the system, and a willingness to follow the contribution guidelines.

Remember that contributions to the documentation are highly prized, and key to the success of the django CMS project.

Development is led by a team of core developers, and under the overall guidance of a technical board.

All activity in the community is governed by our Code of Conduct.

Security issues

Attention

If you think you have discovered a security issue in our code, please report it privately, by emailing us at security@django-cms.org.

Please do not raise it on:

• IRC
• GitHub
• either of our email lists

or in any other public forum until we have had a chance to deal with it.

Development policies

Release schedule & policy

The roadmap can be found on our GitHub wiki page.

We are planning releases according to key principles and aims. Issues within milestones are therefore subject to change.

The django-cms-developers group serves as gathering point for developers. We submit ideas and proposals prior to the roadmap goals.

We officially support the current and previous released versions of django CMS. Older versions are maintained through the community. Divio provides long term support (LTS) through commercial support.

Branch policy

Changed in version 3.3.

We maintain a number of branches on our GitHub repository.

the latest (highest-numbered) release/x.y.z

This is the branch that will become the next release on PyPI.

Fixes and backwards-compatible improvements (i.e. most pull requests) will be made against this branch.

develop

This is the branch that will become the next release that increments the x or y of the latest release/x.y.z.

This branch is for new features and backwards-incompatible changes. By their nature, these will require more substantial team co-ordination.

Older release/x.y.z branches

These represent the final point of development (the highest y of older versions). Releases in the full set of older versions have been tagged (use Git Tags to retrieve them).

These branches will only rarely be patched, with security fixes representing the main reason for a patch.

Commits in release/x.y.z will be merged forward into develop periodically by the core developers.

If in doubt about which branch to work from, ask on the #django-cms IRC channel on freenode or the django-cms-developers email list!

Commit policy

New in version 3.3.

Commit messages

Commit messages and their subject lines should be written in the past tense, not present tense, for example:

Updated contribution policies.

• Updated branch policy to clarify purpose of develop/release branches
• Added commit policy.
• Added changelog policy.

Keep lines short, and within 72 characters as far as possible.

Squashing commits

In order to make our Git history more useful, and to make life easier for the core developers, please rebase and squash your commit history into a single commit representing a single coherent piece of work.

For example, we don’t really need or want a commit history, for what ought to be a single commit, that looks like (newest last):

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

The bottom three commits are just noise. They don’t represent development of the code base. The four commits should be squashed into a single, meaningful, commit:

85d925c Updated commit policy based on feedback.

How to squash commits

In this example above, you’d use git rebase -i HEAD~4 (the 4 refers to the number of commits being squashed - adjust it as required).

This will open a git-rebase-todo file (showing commits with the newest last):

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.

“Fixup” the last three commits, using f so that they are squashed into the first, and their commit messages discarded:

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.

Save - and this will leave you with a single commit containing all of the changes:

85d925c Updated commit policy based on feedback.

Ask for help if you run into trouble!

Changelog policy

New in version 3.3.

Every new feature, bugfix or other change of substance must be represented in the CHANGELOG. This includes documentation, but doesn’t extend to things like reformatting code, tidying-up, correcting typos and so on.

Each line in the changelog should begin with a verb in the past tense, for example:

* 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

New lines should be added to the top of the list.