Steps:
The full process is described at https://github.com/openfoodfoundation/openfoodnetwork/wiki/Releasing.
https://docs.google.com/document/d/1rXLmg7q-wBwnYj7FO6J1KnG172g86Y5k3GPZ5WoBoXA/edit#
Ready to go team. Lovely lovely.
Hey @mkllnk and @lin-d-hop ,
I've stumbled across a loss in functionality in the OC selector. Basically, the clickable area of the OC selected is now significantly reduced, which makes the selector appear as not working. In staging, only the green area (pic below) is possible to activate, to see the drop-down list of open OCs:

In production, it's easy to observe that the whole white area is clickable.
I've double checked on different server/browser combination, but could you please confirm these observations @lin-d-hop ?
I can replicate, I am trying to find what caused this problem.
Looks like the mobile search filters PR #5330 is the only mobile PR in this release. It's quite a big PR, I am trying to understand what commit caused the problem.
ok, this is caused by #5330
I have found the commit that introduced this problem. it's the second commit in #5330
https://github.com/openfoodfoundation/openfoodnetwork/pull/5330/commits/f46ca0c5956084bd5a028d8f580c8fc7587941ff
this line moves the z-index of the tab buttons on the left over the OC selector making the selecor clickable above the tabs line:

I see that the z-index was introduced so that the shadow of the tab buttons is still seen over the search bar or the OC selector (when on mobile). So, it's needed.
I tried playing around with z-index of the OC selector but it's position is "absolute".
@Matt-Yorkley thoughts?
ok, so I created a branch for the patch called 2.9.9
I merged Matts commit and I made that last commit the base for the 2.9.9.
I have updated the link in the description to the build in semaphore, that build can be used to re-stage and re-test the issue and maybe make some final verifications of the release. Ready for testing again.
I've staged and checked that the whole surface of the OC selector is clickable and works as expected. The issue is solved and the release is unblocked :tada:
Blocked label is back on till further clarifications on the issue @Matt-Yorkley found, and in discussion on Slack.
Update: I believe this is the behaviour Matt observed before, now described under issue #5455 (s3?). So I am not sure this is a release blocker. Open to discussion :-)
Hey @mkllnk,
Issue #5467 was also detected as directly concerning this release but, as discussed on Slack in the #testing channel, this should not be a release blocker. So, in this regard, I think it's safe to remove the blocked label, and proceed with the release.