Openfoodnetwork: Release v3.4.1-beta

[mkllnk]

Follow up from #6325.

Steps:

• [x] Include translations: tx pull --force
• x
• [x] Notify #instance-managers of user-facing changes.
• [x] Test: https://semaphoreci.com/openfoodfoundation/openfoodnetwork-2/branches/master/builds/1907
• [x] Update translations if necessary
• [x] Publish and notify #global-community
• [x] Deploy and notify #instance-managers
• [x] Nudge next release manager

The full process is described at https://github.com/openfoodfoundation/openfoodnetwork/wiki/Releasing.

[mkllnk]

This release still has pagination broken on the admin/users page. #6348

The bug has been introduced in the v3.4.x series has only been deployed to France so far. This release will be deployed there first. Further rollout is blocked until #6348 is solved unless another instance decides that they don't need to admin/users page.

[Matt-Yorkley]

The pagination fix is merged, and I've included it in the release and updated the notes and target build :+1:

Lets see how the release goes in testing, but maybe we can remove the -beta flag on this one? The Spree changes have been on French prod for a week and the only bug we found should now be fixed.

[luisramos0]

Hey, I think we also need to fix the calculators problem before we deploy to any other server: https://github.com/openfoodfoundation/openfoodnetwork/pull/6377
It's in code review and needs a quick dev test.
I agree we can remove -beta if we include #6377 :+1:

I am sorry, I could have created this PR 2 days ago :-(

[filipefurtad0]

Ok, I just make a quick verification of #6377 - it can now be included in the release.
Also, we could include #6361 as well.

[luisramos0]

Nice, so we can remove the beta tag.
I see two options:

• Did the manual release testing happened already? If so I'd patch the release with only 6377 and make a quick retest.
• If the manual release tests have not happened yet. I'd remake the release with current master and latest translations and start the release tests.

[filipefurtad0]

I haven't tested the release yet - so I'd say second option :+1:

[Matt-Yorkley]

@filipefurtad0 You can start testing with current master if you want, and I'll look at updating the release.

[filipefurtad0]

Ok, I'll do so - Thanks @Matt-Yorkley!

[RachL]

@mkllnk @Matt-Yorkley @filipefurtad0 @luisramos0 re the "beta" tag. Even with the PR included I would wait for next release to completely remove the "beta" tag.
Maybe there are some stuff we didn't see in FR. It's better to be careful for all other instances?
We could make a rule that a "beta" tag is removed only once all instances managed by global sysadmin pool are updated?

[filipefurtad0]

The release all good to go...
https://docs.google.com/document/d/11y2ki-1_Hb2Hsa9pomqagRoLHf1rQTIouXgPGsU4qu0/edit#

..the only pain point was a regression introduced by #6336 - which is now fixed by #6382 :tada: (still in code review, as of writing)

[Matt-Yorkley]

6282 is now in the release as well :+1:

[mkllnk]

Thank you all. I'm just adding some translation changes and then I'm going to release this as v3.4.1-beta.

Someone renamed it from beta to alpha which is completely fine and legit. But since we use that pre-release identifier (beta) across release versions, it could confuse because alpha indicates an earlier version (Software release cycle). And also according to Semver, pre-release identifiers with letters are compared lexically which also means that beta is newer than alpha. And gamma is newer than beta.

I will provision all servers because there have been changes to ofn-install. I will then deploy this release to all servers as agreed in the product curation meeting. But it will still be marked as beta pre-release because of the higher risk of deploying the bye-bye-spree work.