Update release process

[chompomonim]

Problem statement

At the moment all pull requests are merged straight into master. At some random moment of time we're doing new version releases. In such release there may be set of critical bug fixes, some improvements and experimental features. This in many situations this leads to new bugs, user unhappiness and slow release cycle.

Proposed solution

We could introduce dev branch which all new features would be merged. master branch would be used as "stable" version of software which could be released at any moment of time.

All bugfixes should be merged into master. We could then do more often releases of minor versions (e.g. v0.20.1, v0.20.2 etc.). When we're ready to release set of new features, we would merge dev branch into master and do major release (e.g. v0.21.0). We could also do beta releases out of dev branch (e.g. v0.21.0beta1) and users who would like to try newest features could upgrade into beta. But if something would not work to them, they would always have "safe" downgrade path into stable.

[anjmao]

We could just use GitFlow which solves this problem.

[tadaskay]

Firstly, so that we can better understand the problem statement, could you give an example of one such situation?

in many situations this leads to new bugs, user unhappiness

[chompomonim]

There are plenty of examples.

• After upgrade into v0.17.0 with mobile client (beta) connecting to old nodes was stable, connecting to new nodes became a headache.
• We had to do some fast bug fix in v0.19.1, but instead of simply doing release of v0.19.2 same say and with only that fixes, we had to release v0.20.0 day later which in addition introduced some new bugs in session stability.
• We added broker in one of versions which introduces some problems because consumer apps are not ready.
• Couple of users were reporting that after upgrading from v0.18 into v0.20 he got problems with NAT and nodes are not accessible.
• ... a lot of other bigger or smaller cases where we could fix something same day when bug was found, but had to wait because of other features were in development. Or when we didn't rollout release into auto updates because we needed time for manual testing of chunk of new features.

Also introducing beta would give us more time for manual tests on more different platforms and setups.

[chompomonim]

I do like GitFlow but for having separate branch for each version release looks a little overkill. But if you guys feel that GitFlow is really beneficial for us, we can move into that direction as well.

[tadaskay]

After upgrade into v0.17.0 with mobile client (beta) connecting to old nodes was stable, connecting to new nodes became a headache

We had added compatibility e2e tests to mitigate the issue.

We had to do some fast bug fix in v0.19.1, but instead of simply doing release of v0.19.2 same say and with only that fixes, we had to release v0.20.0 day later which in addition introduced some new bugs in session stability.

If there was a need to do so, we could have made a branch hotfixing a particular release and made a release off that branch instead of master. Current branching model allows that. I believe the intent has not been communicated clearly.

We added broker in one of versions which introduces some problems because consumer apps are not ready.

This is a problem to be addressed by compatibility tests.

Couple of users were reporting that after upgrading from v0.18 into v0.20 he got problems with NAT and nodes are not accessible.

This should be addressed by improving e2e coverage.

... a lot of other bigger or smaller cases where we could fix something same day when bug was found, but had to wait because of other features were in development. Or when we didn't rollout release into auto updates because we needed time for manual testing of chunk of new features.

Current branching model allows that. See explanation above.

---

See, all of these are valid issues. However, none of them require the change of the branching model to be solved (some of them have already been addressed by different means). Changing the model as per your proposal would add the burden of the branch management where our limited development capabilities could be spent in more useful ways, most importantly, solving the actual issues.

[chompomonim]

Moving @zolia proposal here from #1630:

Problem statement

• Improve timely releases with a bit more confidence in quality.
• Ability to backport critical fixes for stable already released versions. (Currently, we aim to support releases for last 30 days)
• Make release cycle more mainnet-like
• Freeze and start testing all main features and new features for all products and main platforms.
• Automate RPI releases with more confidence

Proposed modifications

• Create a new branch for each soon to be released version. For example, we are going to release 0.21.x, we should create such a branch, create a pre-release and start testing it.
• When the team finishes testing, the release is made from that "0.21.x" branch.
• All future critical bugs affecting network operation should be backported to "0.21.x" branch for 30 days since its initial release.

This will require us to identify and set up a manual testing process. We will create a separate ticket for this description for a testing process.