Upgrading and rolling back a client without losing profiles

Two minutes of backup before you upgrade

1. Use the "open app directory" button in settings and copy the whole folder somewhere else. It holds cached subscriptions, your hand-written rules and your UI preferences.
2. If you edited the profile yourself, keep a separate copy of config.yaml or the equivalent profile file somewhere you will find it again.
3. Write down the current version number. You will need it to locate the right tag on the releases page if you roll back.

A subscription URL can always be fetched again from your provider’s dashboard. Hand-written rules and policy groups cannot. That is what the backup is really for.

What to check right after upgrading

• Does the profile still load? A failure normally produces a clear message in the UI, and the log names the offending field.
• Do the system proxy and TUN toggles still behave? If the new version changed its helper service, the first TUN activation may ask for administrator rights again.
• Is launch-at-login still registered? An in-place installer sometimes rebuilds the startup entry to point at the new path. Usually fine, worth a glance.

If the profile errors out, do not roll back immediately. Very often a field was simply deprecated and the log tells you the replacement syntax — a one-line edit. Roll back for missing functionality or crashes, not for a warning you can fix.

Reinstalling an older release

1. Open the project’s releases page, find the tag you want, expand its Assets and download the package for your platform. Older releases are not at the top of the page; scroll down or use the tags list.
2. Uninstall the current version properly, following the usual order — system proxy and TUN off first — so nothing is left behind.
3. Install the older build and launch it before importing anything, just to confirm the program itself starts.
4. Restore your backed-up config directory and restart the client.

Rolling back across a major version — 2.x down to 1.x, say — deserves extra care. Config files written by the newer version can contain fields the older one does not recognise, so restoring them verbatim causes the same failure you were escaping. Use your oldest backup instead, or re-add the subscription and let the client generate a fresh file.

Reducing the odds next time

Do not upgrade at a moment when you need the connection. Day-one releases occasionally ship a regression; waiting a day or two to see whether the issue tracker fills up costs almost nothing.

Also remember the client and the core upgrade separately. If all you want is support for a new protocol, updating the core alone is much lower risk than moving the whole application.