Over the last year we have made huge strides in the consistency of our release process thanks to the regular cadence of releases and the hard work of a very small number of people to test and review pull requests and features.

While we are really proud of the progress we have made, there are some areas that are not working so well, which we are going to address going forward.

Release planning

At the present time of writing, we have 209 open pull requests waiting to be tested and reviewed, however only 67 of these are in a condition that would allow them to be merged. There are various reasons why a pull request would not be mergeable, but the most common reasons that we see are:

• Inadequate automated test coverage
• Automated tests failing
• Conflicts with files that have changed since the pull request was created which have not been resolved
• Lack of documentation to support a new feature or significant change

In the past, we have been assigning a pull request to a milestone (which tells the developer when we are planning to release their change) regardless of whether the pull request was mergeable. If the pull request is not ready to be merged, it just gets bumped back to a later release. In some cases this has been happening for over a year!

Going forward, we will be changing this.

Quarterly release planning

Once a quarter, the Product Team will hold a release planning meeting (open to all) where they will decide what pull requests will be included in the next three releases. These will include two bug fix releases and one minor release (except for the last quarter, which may include a major release):

• Month 1 Patch release (eg 4.0.1)
• Month 2 Patch release (eg 4.0.2)
• Month 3 Minor release (eg 4.1)

The meetings this year will be held on:

• 6th July 2021
• 5th October 2021
• 4th January 2022
• 5th April 2022

All @ 1400 UTC, on Zoom - see the Community Calendar / Product Team Slack for information.

Having reviewed all the previous releases in the history of Mautic, we know that our average over the past two years has been around 20-30 pull requests per release. 

Image

We will therefore only be accepting a maximum of 20 pull requests targeted for each release.

To be considered for inclusion, the pull request must:

1. Have all automated tests passing
2. Maintain, or ideally improve, automated test coverage (as measured by Codecov)
3. Have documentation updates already created and reviewed by the Education Team
4. Be in a mergeable state (have no file conflicts)
5. Have clear instructions in the pull request description for testers to follow which will allow them to:
   1. Reproduce the bug (if the pull request is a bug fix)
   2. Test the fix / test the feature
   3. Understand the areas that the pull request may impact to facilitate full and proper testing

The team will then update the milestone on the pull request accordingly once they have agreed on which are to be included.

Reviewing issues

Of course, pull requests are only one part of the story - we also have to think about the issues that users of Mautic are reporting.

During the release planning meeting, the Product Team will also review the open issues. If there are issues which they feel need to be addressed in future milestones but where there are no pull requests to fix them, they will be able to allocate funds from their bounty budget to those issues and will add them to the appropriate milestones.

The team will at this point accept five new issues per release, taking us up to a hard ceiling of 25 potential pull requests that will be considered for each release.

What about urgent fixes?

We fully appreciate that sometimes there are nasty bugs that are spotted or security issues that need to be addressed. 

The same rules will apply for such fixes to be considered for inclusion in a release as mentioned above. 

The team will do their best to include extra pull requests outside of the agreed scope for the release, however priority will be given to those pull requests that have been planned for inclusion in the milestone.

Areas of focus

The Product Team will also be introducing areas of focus for the quarterly release cycle, where they will be specifically targeting certain features or aspects of the product for improvement.

This will involve there being a bug fix release for two themes, and then a feature release which will focus on both themes.

As an example, the themes for the upcoming release after Mautic 4 are:

• July 2021 Bug fix release (4.0.1) - Forms
• August 2021 Bug fix release (4.0.2) - Campaigns
• September Features release (4.1) - Forms and Campaigns

Named release leads

Taking the role of a release lead is no easy job.  This has fallen to a very small number of people this year, and we want to involve more people in this process.

For this reason we will be having a named release lead for each release, and at least one assistant.  Newcomers to the role will serve as an assistant until they feel confident in leading a release themselves, giving the opportunity to pass on knowledge and involve more contributors in this process.

If you would like to be involved, please join the Product Team on Slack and get involved with reviewing pull requests and testing!

We hope that these changes will serve to focus our efforts on certain areas of Mautic and also give developers and users of Mautic a clearer understanding of what they can expect from upcoming releases.

While we would not exclude pull requests from a release if they are fully ready to be included, we will give first priority to those which are in the milestone, then those that relate to the area of focus. Other pull requests will be considered only if there are not enough to fill the quota for that release.