-
Notifications
You must be signed in to change notification settings - Fork 22
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
Split "Allow incompatible Patches" from "Developer Mode" #333
Comments
Contributes-To: sailfishos-patches#333
Contributes-To: sailfishos-patches#333
Contributes-To: sailfishos-patches#333
Contributes-To: sailfishos-patches#333
Well, that was easier than expected. One thing remains: If users upgrade to this, their "developerMode" (which we present as "Allow incompatible patches" in the UI) setting from an old version will map to "developerMode" in the new version, and "strictCompatability" will default to true (i.e. "Allow incompatible patches" is OFF). While this is probably unexpected, it's "fail-safe", because the dangerous option falls back to a safe default. We could rename "developerMode" something else to force both to defaults, and handle a migration for the now split semantics. Or not - is it important? |
Contributes-To: sailfishos-patches#333
Contributes-To: sailfishos-patches#333
I absolutely concur that the current "Developer Mode" shall be split into two separate user settings, as I already denoted in issue 322.
Indeed, as your three commits show: d2d8387, e712296 and 9fa793e. I also like the fact, that this splits the issues users have been experiencing for so long with the original "Developer mode" from the developer facing issue #322. But …
IMO this is problematic: Most users utilise the current "Developer mode" to override the strict SFOS version check. Hence the current setting of
This is pretty unexpected, even though I like that the fact that your IMO we should try to make this change unnoticeable ("seamless") for most users. I believe that the best approach is to leave the old
As denoted above, I think it is, but rather "handle a migration for the now split semantics" properly for most users and hence (in case of migrating) initialise only the new I know this involves some tedious search and replace, but IMO this is a clean solution to introduce two new settings whose names are not too similar to the old one (also at the UI): This is why I came up with (after some pondering) with the boolean settings |
Good points. As I still want to implement #322 after this, maybe I'll switch the setting to a ComboBox/Enum, something like:
With for now, Strict and Any taking the place of the Boolean Switch, and the other two reserved for the implementation of #322. |
Cool, that would also shorten my suggestion for an appropriate settings name to One thing to consider: Hence I suggest to simplify this scheme and use these three values for
I like this, because it provides the necessary leeway to relax the default from "strict" to "relaxed", if an implementation which resolves issue #322 is not used by Patch developers despite pushing them to (verbally, only 😉). |
"Developer Mode" currently disables (or rather relaxes) the version check, but it also does more, such as enabling the message about old patch.json formats in the Patch Details page.
We should split "Version Check" from "Developer Mode", and offer either as a config option.
Originally posted by @nephros in #322 (comment)
The text was updated successfully, but these errors were encountered: