Development on branches

Some general rules (of thumb)

Please always

• check if you're working on the right branch (see below),
• write good commit messages,
• use feature branches for larger work,
• document your changes in the doc\NEWS file (for core) and the Changelog files (for plugins).

"Good commit messages" include a succinct, meaningful summary for a title and an explanation of the changes you made so one can understand - and meaningfully search for - them, even after months (or years). Please don't just use "fixing it" or "one more thing" or something like that.

Version numbering and release policy

We try to adhere to a semantic versioning scheme, using version numbers in a MAJOR.MINOR.PATCH form.

• Major releases (e.g. 3.0) may introduce breaking changes (but we strive to offer an upgrade path anyway).

• Minor releases (e.g. 2.4) include new features (and bug fixes).

• Patch releases (e.g. 2.3.1) just fix bugs.

Master branch

All regular development is done on the master branch, or on feature branches forked form master.

The master branch will become the next feature release, i.e. a minor release (currently 2.4).

We try to keep the code on master in a working state so that a git checkout is installable and runnable, but there are no guarantees - sometimes work in progress will be merged to master.

Please do consider a feature branch if your work

• is rather large and/or not ready for release, i.e. still work in progress, or
• needs further testing or will possibly contain breaking changes.

Older releases

We keep feature branches for older releases, at least for the last minor release (currently 2.3), so we can fix annoying bugs and security issues.

No original work should be done on those branches unless it's targeted to that release only and should not appear in newer (feature) releases.

Bugfixes will be backported from master as necessary by cherry-picking.

These older release branches have to be kept in a releasable state at any time so security fixes can be backported and released without delay.

Please do not (add or) backport changes that

• have not been tested and/or reviewed,
• are rather large and/or breaking or
• just add new features.

New major releases

When we're working on a new major release, we may choose to use a feature branch (e.g. 3.0) for that so work on master can continue. That will be decided on a case-by-case basis.

Plugins

Please do

• remember to bump the version number for all changes, so they're picked up by Spartacus,
• add all changes to the Changelog file and
• include the (last element of the) plugin name (e.g. staticpage or randomquotes) in the commit title.

Plugin locations (repositories)

Our plugins can mostly be found on Spartacus in the s9y/additonal_plugins repository, but some plugins are bundled with the Serendipity core in the plugins directory.

Very few plugins are bundled in core and on Spartacus. Currently, these are

• serendipity_event_gravatar,
• serendipity_plugin_authors and
• serendipity_plugin_quicksearch

All work should be done on the Spartacus version, i.e. in the s9y/additonal_plugins repository, and backported (copied) to the version in core.

Please do keep those versions in sync; please do not add changes to just one repository. Otherwise, those plugins will have different versions in core an don Spartacus, leading to a big mess.