bolsena2018 version policy discussion

Antonio presented some observations on the community, and opened the discussion for improvement.

Observations:

• Increased activity on the commonutity (measured by nr of PR), but decreased merge rate
• Some PR are merged the same day by somebody from same company, which is considered a bad practice
• Some PR stay open for many months (including merge conflicts), PR-owner should update or revoke (also ping relevant people by direct message if you require some feedback)
• Stable branch receives too many new features, therefore is hard to stabilise

The current approach of putting features on patch releases has partially been born last year, when we assigned develop to hold a big refacture of the code, which has not been released yet. On the other hand companies make promises to customers about new features, that can't wait for the a refacture.

Three suggestions to improve this:

• Do not add features to patch releases
• Release more often (try to release every 6 months) so new features arrive frequently
• Make sure 'master' branch is stable, so some customers can directly use a snapshot version from master.
• Big new features/refactures should be developed in a feature branch. The feature branch is regularly updated against master and pull-requests into the feature branch get reviewed as well, so at some point merging the feature branch into master will be an administrative activity.
• Merging fixes from previous version branches should be done with caution, and preferably with a pull request
• fixes on the current branch, should also be backported to relevent previous version branches, as a guideline

Other suggestions:

• Try to minimise UI changes on patch releases, because it requires users to redo screenshots in documentation.
• Create a roadmap, so users are aware what's upcoming in what version. A roadmap will be dynamic, but we should be able to see 3 months upfront what will be in the next release.
• Let's setup roadmap meetings 1 or 2 times a month (on irc/hangout). Also to notify about important fixes that may have arrived in some branch.
• We deactivate direct commits, only via pull request
• A pull request with potential impact will at least stay open for a day.

Some discussion on if we should distinguish between minor features and major (aka critical) features (where the first could enter in a patch release). For now we suggest to be strict and not allow any features on patches.

Short term:

• Merge 3.4 into develop, rename to 'master'
• in october feature-freeze into a 3.6.x branch and release 3.6 before the end of the year
• next feature freeze will be may 2019 for the 2.8 release
• from 4.0 we'll skip the .2-step in version numbers and will start using 4.1, 4.3...