search

farmOS / field-kit

A modular, offline-first companion app to farmOS.
https://farmOS.org
GNU General Public License v3.0
60 stars 39 forks source link

Work out DNS issues for 1.x and 2.x releases #421

Closed jgaehring closed 2 years ago

jgaehring commented 3 years ago

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.

mstenta commented 3 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?

jgaehring commented 3 years ago

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.

jgaehring commented 3 years ago

As outlined in https://github.com/farmOS/farmOS-client/issues/373#issuecomment-713884184:

jgaehring commented 3 years ago

I think we have a good plan for this going forward, so closing.

jgaehring commented 3 years ago

I think since our timeline has changed drastically we need to reevaluate our strategy here.

jgaehring commented 3 years ago

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?

mstenta commented 3 years ago

Add branch protections to v1 branch (attn: @mstenta).

Done!

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?

Ah good point! Let me take a look at this now...

mstenta commented 3 years ago

do we need to add the https://v1.farmos.app domain to folks farm_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".

jgaehring commented 3 years ago

Woohoo! Thanks @mstenta, I'll add those instructions to the forum topic I draft up later today or tomorrow.

jgaehring commented 3 years ago

Just posted to the forum:

https://farmos.discourse.group/t/migrating-from-farmos-app-to-v1-farmos-app/791

jgaehring commented 3 years ago

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.

jgaehring commented 2 years ago

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.

jgaehring commented 2 years ago

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?

mstenta commented 2 years ago

All makes sense! :+1:

jgaehring commented 2 years ago

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.