Closed jgaehring closed 2 years ago
This makes sense to me. It seems to be the best all-around approach that minimizes disruption, and accounts for the way the service worker, localStorage, IndexedDB, etc will work with domain name.
Prompt users to sync their changes and switch to https://v1.farmos.app when we release 1.0
Curious how/where this would be implemented? Would FK have some logic to detect what domain it's running on, and if it's "farmos.app" show the prompt?
Curious how/where this would be implemented? Would FK have some logic to detect what domain it's running on, and if it's "farmos.app" show the prompt?
Hm, that's an interesting idea, definitely plausable, although sort of a weird detail to have hardcoded in.
My idea was we create a separate branch for 1.x which also acts as the deployment branch (we can setup Netlify to just deploy that branch to that domain). Meanwhile, on the main deploy
branch, which is the one farmos.app is currently pointing at, we do a version 0.7.1, which includes the prompt. Because the 1.x branch will jump from 0.7.0 to 1.0.0, it won't ever include the commits that have the prompt.
As outlined in https://github.com/farmOS/farmOS-client/issues/373#issuecomment-713884184:
develop-2.x
branchdevelop-1.x
deploy-1.x
develop-2.x
into develop
; use that for 2.x going forwarddeploy
branch until we’re ready to release 2.0.0I think we have a good plan for this going forward, so closing.
I think since our timeline has changed drastically we need to reevaluate our strategy here.
v1
v1
to https://v1.farmos.app.v1
branch (attn: @mstenta).v1-migration-warning
(no branch protections, b/c we may periodically rebase this branch on v1
).v1-migration-warning
, add warning banner: “Please migrate to v1.farmos.app etc”v1-migration-warning
branch (instead of deploy
branch) to https://farmos.app.develop
branch, which will still deploy to https://develop.farmos.app for live testing.deploy
branch at v0.8.2
tag for now, until 2.0.0 is ready to launch.Remaining question: do we need to add the https://v1.farmos.app
domain to folks farm_access
settings on farmOS? Can we do this easily for Farmier accounts, and maybe write up a simple how-to for self-hosting folks?
Add branch protections to
v1
branch (attn: @mstenta).
Done!
Remaining question: do we need to add the
https://v1.farmos.app
domain to folksfarm_access
settings on farmOS? Can we do this easily for Farmier accounts, and maybe write up a simple how-to for self-hosting folks?
Ah good point! Let me take a look at this now...
do we need to add the
https://v1.farmos.app
domain to folksfarm_access
settings on farmOS?
Done: https://github.com/farmOS/farmOS/commit/5a6c1e9407ee71fc7653bf861dcb4fb475353ed9
This is deployed to all Farmier-hosted instances.
As for self-hosted instances, this will automatically take effect unless they have manually submitted the /admin/config/farm/access
settings form (in which case the old default will have been saved to the database). Otherwise, they should see https://v1.farmos.app
appear in that form automatically, and it should "just work".
So instructions can be:
Go to [your-farmOS-hostname]/admin/config/farm/access and confirm that
https://v1.farmos.app
is in the list. If it isn't add it to the bottom and click "Save configuration".
Woohoo! Thanks @mstenta, I'll add those instructions to the forum topic I draft up later today or tomorrow.
Just posted to the forum:
https://farmos.discourse.group/t/migrating-from-farmos-app-to-v1-farmos-app/791
Just occurred to me, I wonder if I should update the app manifest on the v1
branch so the app icon on folks' homescreens are easier to distinguish. For reference, it's currently:
{
"name": "farmOS Field Kit",
"short_name": "farmOS",
}
The short_name
is what typically appears below the icon on the homescreen and app drawer; the name
only really appears on the splash screen.
I'm thinking we maybe change it to the following:
{
"name": "farmOS Field Kit v1",
"short_name": "farmOS v1",
}
This might be particularly helpful during migration, so users can install both versions simultaneously, sync both, and still easily distinguish which one needs to be uninstalled.
I'm reopening this since we'll need to work out how we want to migrate back to farmos.app with the release of v2-beta.
As I think we've discussed, I would like to entirely shut down farmos.app prior to deploying v2 on that domain, so we can start off as an entirely fresh install. So are the next steps I'd like to take, which should correspond to individual commits on the v1-migration-notice
branch, which is what is currently being used to build farmos.app via Netlify:
1) Add a final warning to migrate to v1.farmos.app, with a date for when farmos.app will shut down and data will be lost. 2) Add a "trigger" to the service worker, so that the next time an available update is detected, the user will be warned that all data will be lost upon update, and once they do update, clear all caches. 3) Create a static page just notifiying users that farmos.app is currently down in preparation for the launch of v2.
I think commits 1 and 2 should probably happen ASAP, to provide enough time for the warning, with a final shutdown date of, say, Mon, Feb 21. Then we can push commit 3 any time after that shutdown date. Then the domain should be ready for whenever we wish to deploy v2 to it, and all v1 users should be migrated to v1.farmos.app.
@mstenta, does that sound good to you?
All makes sense! :+1:
After looking into this a little further, I realized that step 2 is not really necessary, because v2 is namespaced entirely differently from v1, so the data may still persist on the device, but will not result in any errors.
IndexedDB certainly won't cause problems, since v1 simply used one db called 'farmos'
, whereas v2 will use db's named 'entities'
and 'config_documents'
. It might mean any users, who ignore all the warnings, may end up with some old data left on their device, but that can be remedied any time by logging out or uninstalling.
Local Storage is less of a concern, but if I wanted to be sure, I could just check for the isLoggedIn
key on startup, since I have no intention of ever using that again, and clearing it if it's found, like so:
if (localStorage.hasOwnProperty('isLoggedIn')) localStorage.clear();
Tomorrow I will push the changes for step 1 to the v1-migration-notice
branch, as planned. I have a v1-shutdown-notice
local branch with the changes ready for step 3, which I will push on Feb 22, skipping step 2 entirely.
As proposed in https://github.com/farmOS/farmOS-client/issues/419#issuecomment-698493992, I think it would be good to prompt users to switch to a different DNS for the 1.x and 2.x releases to obviate the need to write migration code between 1.x and 2.x.
Basic idea is:
I think this will be the easiest to coordinate with the server migration, without some level of dual support. It will be a little effort for users, but at least it will make it clear which version to use depending on what version server their running.