Change update branches strategy

[JohnMertz]

This is an aspirational outline of how I would like updating and branches to work upon MailCleaner Next going stable. This should provide a distinct update experience for Community Edition (CE) and Enterprise Edition (EE) as well as better tools to test specific experimental features. The current process is described first, for posterity, then the aspirational plan is laid out. Adjustments are possible before and throughout the Next lifecycle.

Current branching process

MailCleaner development is done using Git and updates distributed via GitHub. Historically, this has been done by having developers fork, contribute to a branch on their fork, then use a Pull Request to merge into the 'master' branch. This methodology allows anyone to contribute and for changes to be tested by checking out those pull requests onto a testing machine before merging.

However, this methodology is inflexible at best and having no intermediate step between limited testing on those development machines and pushing out to the entire user-base has proven to be insufficient for testing all possible side-effects.

Changes are applied by the Updater4MC repository and it will choke and abandon all updates if either it's repo or the MailCleaner repo are not currently checked out of 'master'.

Aspirational branching process

All new features and fixes, aside from very simple or critical fixes will continue to be made on dedicated branches, with PRs opened against 'master'. A new version of Updater4MC should be created which can accommodate non-master branches so that it does not cause other updates to be blocked. Providing it with an argument to Updater4MC should handle checking that branch out automatically. Being on an experimental branch should appear somewhere in the WebUI.

For contributors, CE users and unregistered users, not much should change because these will be configured to track the 'master' branch. Contributors (staff or community) will be encouraged to track 'master' also, when not on a development branch even if they are registered for EE.

These commits will be tested similar to how they always have been before merging. These users will function as a wider testing community for EE.

'stable' branch

There will be a new 'stable' release introduced which will absorb commits from 'master' on a delay of a couple of days or weeks to catch any bugs that might have been introduced. This branch will be the default branch checked out by EE users. There should be some minimum amount of friction to discourage CE users from being able to check out this branch also. If it is coded into Updater4MC, then any effort to subvert it should result in Updater4MC refusing to pull changes. This would still be fairly trivial to work-around, but we can rely on the goodwill of our community to generally not do so.
They will get the benefit of immediate access to new features while helping to ensure a more stable experience for our paid subscribers who help keep MailCleaner running. It is not in anyone's interest to requires us to spend time implementing any stronger safeguards.

When an appliance registers for EE, it will need to wait until it's current commit has been absorbed into 'stable' before it can reliably change the branch that it tracks since temporarily removing a feature that they have already had could be disruptive.

The relationship between CE and EE edition should therefore be analogous to the relationship between Fedora Linux and RHEL, where Fedora also gets the latest features immediately, but is also a testing ground to ensure that those features are as stable as possible before being adopted by the premium users of RHEL. CE is a community driven project where most of the new work is done, while EE is much more of in in-house exercise in managing the release of CE patches and providing premium support to those EE clients.

'feature' branches

It is possible that we may have a need to provide optional functionality on a more select basis. To allow for this, the 'Updater4MC' should be updated to allow for a declaration of the branch you would like to start tracking. This should be done like:

$ /root/Updater4MC/updater4mc.sh --mc-branch=feature --u4mc-branch=testing

This will checkout the branch 'feature' for '/usr/mailcleaner' and 'testing' for '/root/Updater4MC'. Those values would probably need to be store somewhere like:

/var/mailcleaner/spool/updater/mc-branch
/var/mailcleaner/spool/updater/u4mc-branch

so that the updater script can check the branch that it should be pulling from if no argument is provided. Using 'master' or 'stable' for each should resume tracking the production branch for CE and EE respectively. This is where the limited effort should be made to prohibit CE users from entering 'stable'.

Feature branches may be utilized to implement 'tags' to introduce an additional level of feature stability by locking that branch at a specific revision.

Note that we cannot guarantee functionality for checking out feature branches which are behind the latest commit. As with new EE registrations, it could introduce problems if already applied functionality is later removed.

The future

In the future, we will be looking to provided as many system components as possible as containers. In this paradigm, the container images will be similarly versioned with 'stable' and 'latest' where EE users will pull the former. Development will continue in GitHub, but the method for deploying MailCleaner will need to change to host container images and fetch new versions of those images with Updater4MC.

Contributing

If you'd like to contribute to MailCleaner, please see the Contributing Guide