4 ms·

> So, make it an old parameter by having this from the beginning in your language. It's already part of PowerShell. You can request a specific version when yo

by dpark 10y ago

> So, make it an old parameter by having this from the beginning in your language. It's already part of PowerShell. You can request a specific version when you run PowerShell. https://msdn.microsoft.com/en-us/powershell/scripting/core-powershell/console/powershell.exe-command-line-help#version-windows-powershell-version https://msdn.microsoft.com/en-us/powershell/scripting/core-p... > Users can use it proactively, before something breaks. It can be a recommended practice for deploying code. I'm sure it is recommended practice. That's irrelevant if people aren't following that best practice. And they generally aren't, because it adds friction to development. The "go back in time and do it right from the beginning" fix isn't feasible due to the lack of reliable time machines. > It is substantially better than asking people to change source code. It's really not. If the workaround avoided compilation, this would be lower cost. But the cost to make a small change to a script and the cost to change the way the script is invoked are pretty much the same. > Windows has versioning mechanisms in some of its API's, by which it can tell that a program is calling it that was compiled for an old version. No. Windows is just super-serious about backwards compatibility. Some APIs are versioned. Most are not. Microsoft just bends over backwards to keep stuff running (to the point of emulating bugs that programs relied on). > Speaking of browsers, web pages declare what version of HTML they are in with <!DOCTYPE ...>. If your page begins with <html>, you can't expect it to render the same way everywhere. Also no. HTML5 did away with the versioned doctype crap because it wasn't actually useful. It's just "<!DOCTYPE html>" now, because that's what you need to get browsers to render your site in a standards-compliant way. > Backward compatibility is the normal modus operandi. This type of mechanism is just for "oh shit" situations: there is no way we can fix this thing while remaining backward compatible. Any newly introduced use of the version emulation is treated with great regret. This type of mechanism 1) already exists for powershell, and 2) doesn't really help much here. I'm sure if they take this breaking change, they'll advise impacted people to use this workaround if they cannot for some reason fix their scripts. But this is not a "fix". Disclosure: MSFT employee, but not on PowerShell or Windows

kazinator 10y ago
I never called this a "fix". I used "fix" in reference to whatever backward incompatible change was being made to make this workaround necessary. (For whatever reasons, it is considered a fix that is desirable; and so the question is then now to mitigate the impact.) Of course the fix for any behavioral regression is to make it go away without the user having to do anything (other than apply the fix). The versioning request mechanism has to be supported via an environment variable also, because if a user has a tree of scripts calling each other, it may not be feasible to insert this extra argument into all those calls. > But the cost to make a small change to a script and the cost to change the way the script is invoked are pretty much the same. That is true, but the cost to make hundreds of changes to a script versus one command line parameter isn't the same. A change which breaks backward compatibility could affect some programs in many places. There is also the cost of finding that there is a problem, and what that problem is: where is it breaking and what changes need to be made. All while ensuring that those changes work for the older versions of the interpreter too, not just in the upgraded environment. Say I have some big, 10000 line script. I update to a new interpreter, and the script doesn't work. First thing I will try is the compat option to emulate the previous version. If it works, then there is my workaround; for the time being, I don't have to care why, or whether forty places in the script are affected or only three. The thing has a way of continuing to work (for a good, long time) so I have plenty of time to investigate it. I can treat it as a low-priority issue and give it as a background task to a co-op student instead of as an urgent blocking issue. > HTML5 did away with the versioned doctype crap because it wasn't actually useful. It's just "<!DOCTYPE html>" now, I.e. HTML5 just shortened the spelling of the utterance that you need to indicate that "this page is HTML5". If your page is HTML4, you need the older, more verbose utterance.
- dpark 10y ago
  > I never called this a "fix". You called it a solution. You called it a way to address the issue. Nitpicking use of the specific word "fix" is pointless, when you were clearly proposing this as a fix. > That is true, but the cost to make hundreds of changes to a script versus one command line parameter isn't the same. A change which breaks backward compatibility could affect some programs in many places. You're right. The cost to hack it with a specific version is higher. You either have to set a system-wide environment variable (which someone will forget about and ship a break because locally they were using a newer version) or you have to inject it at each point a relevant script could run. Or you could do a find/replace for the problematic alias and be done. > There is also the cost of finding that there is a problem, and what that problem is: where is it breaking and what changes need to be made. All while ensuring that those changes work for the older versions of the interpreter too, not just in the upgraded environment. It's literally a grep/findstr. I don't know why you're acting like it's hard to find uses of the tokens "curl" and "wget" in ps1 files. > Say I have some big, 10000 line script. I update to a new interpreter, and the script doesn't work. First thing I will try is the compat option to emulate the previous version. If it works, then there is my workaround; for the time being, I don't have to care why, or whether forty places in the script are affected or only three. The thing has a way of continuing to work (for a good, long time) so I have plenty of time to investigate it. I can treat it as a low-priority issue and give it as a background task to a co-op student instead of as an urgent blocking issue. What are you talking about? The whole reason to maintain backwards compatibility is so you don't end up in this situation. You can use the version switch if you need to, but in general if you need to in production it means someone screwed up. In the scenario you described, there's a 95% change you'll never take the version switch off once it's in place (because it's "low priority"), so you'll have this hanging over your head until something breaks and it becomes critical to upgrade, at which point you'll be frantically trying to fix the problem and cursing Microsoft for not maintaining backwards compatibility. > I.e. HTML5 just shortened the spelling of the utterance that you need to indicate that "this page is HTML5". If your page is HTML4, you need the older, more verbose utterance. Not exactly. If you slap the "HTML5 doctype" on an HTML4 page, it's expected to work. Because again, that abbreviated doctype is all you actually need to get a browser to use standards-compliant mode. But also, this is the doctype going forward. So far as I understand, there is no plan for HTML6/7/whatever to change this. Because backwards compatibility is greatly preferred over trying to force a specific version.

by dpark 10y ago

kazinator 10y ago

I never called this a "fix". I used "fix" in reference to whatever backward incompatible change was being made to make this workaround necessary. (For whatever reasons, it is considered a fix that is desirable; and so the question is then now to mitigate the impact.) Of course the fix for any behavioral regression is to make it go away without the user having to do anything (other than apply the fix). The versioning request mechanism has to be supported via an environment variable also, because if a user has a tree of scripts calling each other, it may not be feasible to insert this extra argument into all those calls. > But the cost to make a small change to a script and the cost to change the way the script is invoked are pretty much the same. That is true, but the cost to make hundreds of changes to a script versus one command line parameter isn't the same. A change which breaks backward compatibility could affect some programs in many places. There is also the cost of finding that there is a problem, and what that problem is: where is it breaking and what changes need to be made. All while ensuring that those changes work for the older versions of the interpreter too, not just in the upgraded environment. Say I have some big, 10000 line script. I update to a new interpreter, and the script doesn't work. First thing I will try is the compat option to emulate the previous version. If it works, then there is my workaround; for the time being, I don't have to care why, or whether forty places in the script are affected or only three. The thing has a way of continuing to work (for a good, long time) so I have plenty of time to investigate it. I can treat it as a low-priority issue and give it as a background task to a co-op student instead of as an urgent blocking issue. > HTML5 did away with the versioned doctype crap because it wasn't actually useful. It's just "<!DOCTYPE html>" now, I.e. HTML5 just shortened the spelling of the utterance that you need to indicate that "this page is HTML5". If your page is HTML4, you need the older, more verbose utterance.

dpark 10y ago
> I never called this a "fix". You called it a solution. You called it a way to address the issue. Nitpicking use of the specific word "fix" is pointless, when you were clearly proposing this as a fix. > That is true, but the cost to make hundreds of changes to a script versus one command line parameter isn't the same. A change which breaks backward compatibility could affect some programs in many places. You're right. The cost to hack it with a specific version is higher. You either have to set a system-wide environment variable (which someone will forget about and ship a break because locally they were using a newer version) or you have to inject it at each point a relevant script could run. Or you could do a find/replace for the problematic alias and be done. > There is also the cost of finding that there is a problem, and what that problem is: where is it breaking and what changes need to be made. All while ensuring that those changes work for the older versions of the interpreter too, not just in the upgraded environment. It's literally a grep/findstr. I don't know why you're acting like it's hard to find uses of the tokens "curl" and "wget" in ps1 files. > Say I have some big, 10000 line script. I update to a new interpreter, and the script doesn't work. First thing I will try is the compat option to emulate the previous version. If it works, then there is my workaround; for the time being, I don't have to care why, or whether forty places in the script are affected or only three. The thing has a way of continuing to work (for a good, long time) so I have plenty of time to investigate it. I can treat it as a low-priority issue and give it as a background task to a co-op student instead of as an urgent blocking issue. What are you talking about? The whole reason to maintain backwards compatibility is so you don't end up in this situation. You can use the version switch if you need to, but in general if you need to in production it means someone screwed up. In the scenario you described, there's a 95% change you'll never take the version switch off once it's in place (because it's "low priority"), so you'll have this hanging over your head until something breaks and it becomes critical to upgrade, at which point you'll be frantically trying to fix the problem and cursing Microsoft for not maintaining backwards compatibility. > I.e. HTML5 just shortened the spelling of the utterance that you need to indicate that "this page is HTML5". If your page is HTML4, you need the older, more verbose utterance. Not exactly. If you slap the "HTML5 doctype" on an HTML4 page, it's expected to work. Because again, that abbreviated doctype is all you actually need to get a browser to use standards-compliant mode. But also, this is the doctype going forward. So far as I understand, there is no plan for HTML6/7/whatever to change this. Because backwards compatibility is greatly preferred over trying to force a specific version.