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
rethink deprecated/ESR/updater #1733
Comments
Latest version is fine, just make sure to run the updater with the esr option (-e or -esr). |
I don't use the updater at all, so I can't vouch for the esr option. Since I changed the format (in v118, upcoming) I think that command is now useless So what did people do in the past to keep the ESR version of AF but make changes. Probably just add them to the end and keep a copy in an overrides ? |
It's broken for v118 but just needs a tiny fix. |
what's the tiny fix, so I can add it |
don't forget that the values are blanked and al the prefs are commented out |
Just to be clear, the whole point I did this was to force users on ESR to use the 115.1 AF version - I totally forgot about the updater (and commands) |
I need to drink on this. What I might do is blank and comment out the shit ESR shouldn't use, but leave the others in. And I will also add a warning at the top that you're on your own )e.g. when I move to FPP, ESR users will fail on that front since it wasn't even hooked up |
Windows, line 145: I see that section 9999 now has a 9998. That doesn't make any sense. How do you want to handle that, like 999x? In that case for Linux, line 285: |
does to me :) it's only for one release, because v119 I strip out all the old ESR102 shit, and I wanted to split them so in the past (for the 4 release overlap of ESRs: I needed to keep them an extra cycle so once EOL it was still there the next release for prefsCleaner), and depending on if there were any deprecated items .. it looked like this (using 102 + 115 as an example) /*** [SECTION 9999]: DEPRECATED / REMOVED / LEGACY / RENAMED
Documentation denoted as [-]. Items deprecated prior to FF91 have been archived at [1]
[1] https://github.com/arkenfox/user.js/issues/123
***/
/* ESR102.x still uses all the following prefs
// [NOTE] replace the * with a slash in the line above to re-enable them
// blah blah
// ***/
/* ESR115.x still uses all the following prefs
// [NOTE] replace the * with a slash in the line above to re-enable them
// blah blah
// ***/ So does the esr option flip both? If so, that's a little messy, but not a deal breaker, because setting deprecated prefs won't do anything - e.g. if you're on ESR115 and you set ESR102 prefs - but then I remove those and prefsCleaner never gets to "clean" the active ones It's all a bit messy, and quite frankly, I want to do away with the ESR section and deprecated. I will still list deprecated, but I think I will just stick it all under 6050s what the updater needs is a command to skip updating the user.js and just go straight to appending overrides (and to remove the esr option) Class, discuss! Speak now or forever hold something |
What I always do: |
@g-2-s yeah, that's how I would do it - i.e not use the updater because I do not want the latest version, and just manually add my overrides (and keep a copy), and of course run prefsCleaner prefsCleaner is only needed once per release - but if you adding then removing overrides of inactive prefs in the user.js, then it helps - i.e there are edge cases where prefsCleaner absolutely helps and saves your ass, and running it cannot hurt you example
|
That's probably the most straightforward solution for the future. From reading the conversation until now, what I've understood is that I'll have to manually edit both the user.js and the overrides files simultaneously for whatever pref I'm changing, and then run prefsCleaner. |
@opusforlife2 yeah, for now. I need to drink on this - the updater will always get the latest version, and by the time ESR users reach EOL, they don't even get the next ESR release, because we're three releases past that. So
|
Maybe a separate naming scheme for ESR releases + different release channels? Regular and ESR? |
not going to have two release channels - once the ESR version is released, that's it |
some notes/thoughts ESR78-91 transition - I added the ESR91-102 transition - the order was reversed - 91 first then 102. I think this is the correct/best order so at least the older ESR is flipped with the esr option. So ESR102-115 transition - order maintained, i.e 102 first then 115 😁 I only have to do this once a year, so I guess It's whatever my brain says at the time. We would remove the [1] So each transition we end up with two lots of ESR flips, with the newer lot having at least 1 active pref - sometimes super important like cookieBehavior, sometimes minor shit like MS family safety. IDK if the esr-option flips both. For the actual changeover release, I can move the old ESR to 6050s, because by then the order should be reversed (assuming only 1 char flip) This is why I do not want to deal with the entire 9999 section and an esr-flip. It gets so convoluted and messy. |
OK
@opusforlife2 , does this cover your concerns
|
@opusforlife2 - also see https://github.com/arkenfox/user.js/wiki/3.4-Apply-&-Update-&-Maintain#-esr-users awaiting your feedback so I can close and get back to drinking - thanks for the improvements, which were clearly needed ;) 👍 |
I'm only stuck on ESR because of Windows 7. Otherwise I would have updated regularly. So the part relevant to me is the exact process for safely making changes to prefs without accidentally updating the user.js. Basically this part:
If you want to put that in the wiki for other ESR users, it would need a separate heading, I think. But if there is going to be a command for strictly locally updating the user.js like you mentioned above, then this doesn't need to be mentioned. |
there won't be an command to only append overrides unless someone does it - but I'll add an issue the wiki and user.js already say what you asked |
I don't know, maybe I'm misinterpreting something. The stuff you've referred or linked to only talks about updating to a new version, whether release to release or ESR to ESR. Not about staying on the same version and still wanting to change a pref around. |
here's the user.js (v118 when I land it)
here's the wiki - https://github.com/arkenfox/user.js/wiki/3.4-Apply-&-Update-&-Maintain#-esr-users
|
Maybe we're talking past each other? I'll propose some edits to the PR. |
I'm using the 115.1 ESR user.js. Now I want to edit some prefs in my overrides. But running the updater will download the latest user.js instead of the ESR.
My intended approach is to point the Github URL in the updater.bat to the 115.1 release.
Is this the correct way, or am I missing something?
The text was updated successfully, but these errors were encountered: