-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HybridApp] Update the force upgrade modal to distinguish between prod and staging environments. #52276
Comments
Asking about next steps here. CC: @staszekscp |
Just to confirm the scope of the task 😄 The desired behaviour is to:
|
I don't think (2) is required for this issue. We need to force upgrade production users of the NewDot app, and keep shipping new builds to staging such that we can continue testing bugs to determine if they're HybridApp only or not. |
In this case I think we can take care of that when we'll align the HybridApp deployment to NewDot! When it happens we can take care of that, so it doesn't happen to soon 😄 |
Cool, I think we just merged that PR didn't we? #52283 |
Ok then! We'll jump into this on Monday! |
Hey @staszekscp, is there anyone specifically that I can assign this issue to? |
Hi @Julesssss 👋 I'm going to work on this :) |
Great, let me know if I can help with anything. |
@trjExpensify we should think about testing. It's going to be tricky so maybe we just have to manually verify on the PR that bumps the minimum once these changes are deployed and we are ready to kill standalone? |
Hm yeah, I'm not actually sure how to test that beforehand on staging, given it's a solution to force upgrade production only. When we deploy to staging the PR to bump the minimum version, could we minimally test that staging environments aren't blocked? 🤔 |
I think we should add a beta to test this, so we can confirm on known test domains and then enable it for all domains. |
Added in https://github.com/Expensify/Web-Expensify/pull/44480, the beta name will be |
PR merged, awaiting deployment for testing |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.66-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2024-12-03. 🎊 For reference, here are some details about the assignees on this issue:
|
@Julesssss can we close this? |
@trjExpensify I want to keep it open a bit longer as it hasn't been tested properly yet. It can be closed as soon as internal QA occurs for this backend PR. |
Works for me! |
We're still waiting to confirm this, Melv. |
@Julesssss, @trjExpensify, @war-in Whoops! This issue is 2 days overdue. Let's get this updated quick! |
Still held up on confirming this. |
@Julesssss, @trjExpensify, @war-in Uh oh! This issue is overdue by 2 days. Don't forget to update your issues! |
|
Coming from here.
Parent issue
Problem
When we deprecate the NewDot standalone app, it causes us to not be able to test whether bugs are /app or /mobile, which prevents us from confirming if the issue can be external or internal.
Why is this important?
To protect internal engineering resources and maximise the use of our external contributors. This is also a blocker to deprecating the app, which increasingly causing more confusion amongst users.
Solution
In doing so, we can continue shipping NewDot standalone builds to staging environments (i.e Testflight) and maintain our ability to test for HybridApp only bugs.
Issue Owner
Current Issue Owner: @trjExpensifyThe text was updated successfully, but these errors were encountered: