Bump to 1.5.0

[Duddino]

Abstract

Bump MPW to 1.5.0, to follow this new proposed release model:

Branching:

• The master will always push to the future release: We recently released 1.4.0, so we are now developing 1.5.x.
• For each release, a new branch will be created, which will only receive cherry-picks from bug fix PRs.

Pull request guidelines:

To maintain clarity during the development of both versions:

• If a PR is only relevant to the next release, it can be created as normal.
• If a PR is only relevant to the current release, it can be created with the current release branch as base. Currently 1.4
• If a PR is relevant to both the current and next release, it should be created to master and have include a cherrypick-stable label. It will be the duty of the PR merger to cherrypick the commit to the stable branch.

Additionally, a new section was added to the PR template. This is done mainly to remind developers that the changelog is to be updated per PR, rather than before the release: This allows us to eventually automate the bump version PRs.

Monthly Version Bump and QA

On the 1st of each month:

• Create a new stable branch with the nomenclature 1.x, (e.g. 1.5, not 1.5.0). This is because we release the 1.x.y release from the 1.x branch.
• Open a PR to master and increase the version by one.
• Push the newly created stable branch to QA for testing.
  This will give us 10 days to fix any bugs that pop up. Any new features merged into master after the first of each month will therefore not make it into the upcoming release.

Translations

A translation PR can be opened after the first of each month, with master as the base and cherrypick-stable as label.

---

Testing

No testing is required.

---

PR Checklist

I have:

• Tested that the code functions as expected.
• Ensured the code is properly formatted using npm run prettier.
• Updated the changelog with the relevant changes.

[netlify]

✅ Deploy Preview for cheery-moxie-4f1121 ready!

Name	Link
🔨 Latest commit	2c7a78c
🔍 Latest deploy log	https://app.netlify.com/sites/cheery-moxie-4f1121/deploys/6553d9cf145eb400092c4f70
😎 Deploy Preview	https://deploy-preview-259--cheery-moxie-4f1121.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[JSKitty]

Just so I know I understand fully, with examples:

• Immediately after the next release, a new branch is created for it's successor (v1.6.x?).
• Feature or other large PRs would end up in the successor branch (v1.6.x).
• Bugfixes that apply to Current and Successor would end up in master.
• Every 1st, the Successor branch is PR'd to master by me, and PR tested by QC team until the 10th.
• Repeat.

Correct?

Only thing I'm a bit unclear on currently is when/where i18n "bulk rounds" get merged, Master? Successor? What if both branches had string changes?

I also think another "checkbox" should be: "[x] I have updated the translation template with any string changes". - which will prevent awkward cases that someone accidentally hardcodes a string, delaying merge.

Otherwise, I like it, and I think I can help automate a lot of this with Prodder by, i.e: automatically compiling an i18n list, pinging the translators for us, pinging the QC team with direct links to the test deployments.

[Duddino]

Just so I know I understand fully, with examples:

* Immediately after the next release, a new branch is created for it's successor (`v1.6.x`?).

On the 1st: Create a branch for the upcoming release (1.5 on 2023/12/01), and update package.json on master to 1.6.0
On the 10th: Create a new release pointing to the tip of the 1.5 branch
It's as if the 1.5 branch is master up until the 1st

* Feature or other large PRs would end up in the successor branch (`v1.6.x`).

On master

* Bugfixes that apply to `Current` and `Successor` would end up in `master`.

They would end up on master and 1.4

* Every 1st, the Successor branch is PR'd to `master` by me, and PR tested by QC team until the 10th.

A bump to 1.6.0 PR is created on master and the 1.5 branch is created

* _Repeat._

Other projects do something like this, check Godot for example. They are developing the 4.2 branch on master, and maintain the other releases through a similar process.

The way you outlined would also be good, the main issue is that I expect master to have the most bleeding edge version, but I do know that it's not true for all projects.

Only thing I'm a bit unclear on currently is when/where i18n "bulk rounds" get merged, Master? Successor? What if both branches had string changes?

Ideally they would be done after the 1st on master, with the cherrypick label. Translation is usually adding string rather than modifying, so it should be easy to manage.

Other potential scenarios:

It's the 1st, but there is not enough work to warrant a new 1.x release

We can merge master into the current stable branch and begin testing, keeping master as 1.(x+1)

There is a really big PR that warrants a 2.0 release

That PR will change package.json to the 2.0 version, so if it's merged before the first we will release 2.0, otherwise 1.5