Managing the 1.14.0 release process

[Francesco Casella]

As discussed today in the devmeeting, we need to allow people that are developing new features to merge them into master. At the same time, we need to manage the last remaining issues with replaceable and, last but not least, keep supporting users that are currently relying on the nightly build (the latest release is 9 months old now) and shouldn't get disrupted in their daily work.

For this purpose, I would make good use of stable releases, as described, e.g., in the ​windows and ​linux download pages.

My suggested course of action:

1. @mahge930 reverts his last commits, if they caused regressions
2. @adrpo branches 1.14.0-dev.01 off master, makes it a stable release, and updates the download pages (​windows and ​linux) so people can access all the improvments since 1.13.2 until we release 1.14.0 beta and final. I recommend this to avoid any major disruption with nightly build users in the next few weeks.
3. @adrpo branches 1.14.0-dev off master and changes the version number on the master branch to 1.15.0, which we could later upgrade to 2.0.0 if we think we can get to 2.0.0 quality in a reasonable amount of time, otherwise we'll release whatever is available in 1.15.0.
4. The development of new features (e.g. @mahder930's and @niklwors's) can then continue on master. Nightly builds will be made off this version.
5. All the bug-fixes related to 1.14.0 blockers will have to be merged both into master and into 1.14.0-dev
6. As soon as @adrpo manages to merge replaceable support on 1.14.0-dev, we release 1.14.0-dev.beta1. This will supersede 1.14.0-dev.01 as the latest stable release for Linux users. Of course replaceable should also be merged on master.
7. Any other 1.14.0 blocker fixes will have to be merged in 1.14.0-dev until we release 1.14.0.
8. After the 1.14.0 release, @adrpo branches 1.14.0-dev into maintenance/v1.14. Any further 1.14 blocker fixes should be merged there and eventually be released as 1.14.x, if they can be cherry-picked with a reasonable effort.

I would recommend steps 1. and 2. to be carried out asap, preferably this week.

Feel free to comment and/or improve

[Francesco Casella]

Results of the discussion of today's webmeeting:

• branch off 1.14.0 today, to make a stable release without replaceable support available to the public before we run into potential issues with that. This is our insurance policy against any potential issues with replaceable support.
• Make a 1.14.0-dev.beta1 from that branch today, test it for one-two weeks and then release it. There are a few regressions w.r.t. 1.13.2, namely #5606, #5631, #5662, that we should try to get into 1.14.0 during the beta test period or possibly later cherry-pick them into 1.14.1.
• branch off 1.15.0 today, or possibly in a few days, that will include replaceable, and possibly also some other fix among the current 1.14.0 blockers. The testing will be made through 1.15.0-dev.betaXX releases, which are ran by Jenkins and can be installed by end-user without compiling from sources
• continue the development of new features on master, which will be named 1.16.0. All commits to 1.15.0 should eventually be merged into 1.16.0, once they are stable.

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

The plan has been implemented