Calligra/Policies/Commits

Note

This is a draft

The goal of this policy is to provide guideline on what to commit to the main development branches of calligra: master, futurestable and stable.

This policy should not be seen as a frame to prevent developers to have fun and creativity, its main goal is to ensure that the Calligra project is able to release timely update to its user base while keeping a high quality standard.

Branches

• master: this is the main development branch, it is always open for new features and bug fixes
• futurestable: is a branch that is fork from master a few weeks before release, it is close for new features, only bug fixes are accepted
• stable: this is the maintenance branch after a stable release, also closed for features

Commits in master

The goal is to keep master in a state where it is releasable at all time: as stable as possible. Which means that the feature that are in master should be finished and stable, therefore it is highly recommended to develop new features in a branch.

Then commits in master are restricted to:

• single commit bug fixes
• merge from feature branches (or single commit feature)

As for merging a feature branch, it should only happen once the feature is release ready, ie when there is no known (serious) bug and no known crashes. It does not mean the feature is judge "complete", but it should be already useful. For instance, if you implement spell checking, the desirable complete feature include highlighting of mistakes and offering corrections, it would be acceptable to merge after implementing highlighting, and then a second time after the correction UI is in place.

It is also recommended to apply caution when committing to master, and it is often advisable to get review from fellow developers, especially when committing to libraries or to critical code (like loading and saving), for more practical rules on reviewing, check the review board rules.