Add compatibility info #30
Comments
|
Could this be driven by the community as well? Author tested and community tested? The author could mark the versions/browsers/methods that they confirmed working and users could mark a "works for me" or something along those lines? |
|
Yes, that would be good, possibly tied into the discussion system. |
|
I want some more feedback. Posted to https://greasyfork.org/forum/discussion/1933/potential-new-feature-script-compatibility |
|
@arantius @derjanb @johan @sizzlemctwizzle @Martii @gera2ld (please @ others if you think they'd be interested) I'm proposing a new meta-data key that describes the script's compatibility in a given browser or user script manager. There's been some discussion on the Greasy Forum and script authors seem interested in this feature. I think this metadata would be informational only: user script hosting sites would display it to users before they installed, but user script managers wouldn't prevent a script from being installed if it's marked as incompatible. @tobias-engelmann has a suggestion for the syntax: // New version with value1, value2, value3 but follows the rules.
@compatibility <browser/addon identifier> <status> [<comment>]
// Example:
@compatibility opera maybe Works in Opera 12, untested Opera 15
@compatibility opera-tampermonkey true Some comment
@compatibility opera-violentmonkey falseSome potential issues:
|
Agreed... it's also possible down the line a newly supported browser may have a split name too.
Basically this should imply "tested under/on" ... so not sure if anyone would want it clearer than just "compatibility"... IDK. I think we need to see what the other user.js engine maintainers think first. |
|
A Firefox extension specifies (repeated) In the past the phrase we've used is "user script engine" to refer to things that can run user scripts, be it a native browser feature or any kind of installable add-on. |
|
Does Chrome/Chromium/Opera/Safari/IE/etc. have a similar |
|
I think we really want to limit the number of possible keys, because this should be "a a glance" information, whether by someone looking at the code or by a site parsing it out and displaying it. I think we could say that:
That would limit the keys just to the possible engines, while retaining any information the author chooses to include. |
|
This sounds good to me cause it I think it expresses what the script author wants to describe. Maybe we should also allow multiple comma separated browser+addon(optional) fields to not enforce a Shortened specifiers might also help. Another thing is maybe the status should be in front of the supported combinations. For statuses I'd vote for "full", "partial" and "none" to express full compatibility, partial compatibility with a maybe limited feature set and no compatibility at all. And finally also versioning doesn't look too bad to me: |
|
My syntax was based on the existing syntax of the keywords of the addons. There is no such feature like adding multiple references at once (if you specify Abbreviations were left out as there might be many users which don't know them and it's easier to understand if you have full names. My opinion: Only use abbreviations if it's necessary. And that'S not the case here. Versions were also excluded on purpose as you have the comments for information on things like this. It might be possible that your script works in FF x with GM y and doesn't works in FF z wth GM y. If you only say works in FF+GM(2.0+) you can not reflect this => too many possible options and combinations => better use the comments (especially if you have problems in a specific addon version when another addon was installed). Intention was one line per browser / addon and not multiple lines. |
|
Also,
I was thinking that if something's not mentioned, its compatiblity would be treated as "unknown", so no need to have to specify everything anyway. |
|
Maybe my view is a little bit opinionated by my "user.js engine" background. I'm searching for a value of such a tag and where Tampermonkey would use it.
But it would allow to do some grouping what can make searches easier:
If the version information is machine readable then Tampermonkey can warn the user if some
If a user really wants to understand the full header information then he most probably has to read some manuals anyway. I think you're right as long as there are not too much statements. That's why I would allow both, the full name and well-known abbreviations.
Of course, I just tried to imagine what the author needs to write down if his script supports many or even all combinations. |
|
For those who jump in here, from the previous discussion topic, there was another proposed syntax over there, which is similar to include/exclude : I liked that. |
|
Just to state the obvious, which seems to have been missed in some notes above: Without structured version info, the feature is only useful for nerds reading the source. To get the user experience "works with current version of browser X (or better still, as the TM maintainer notes: my current browser and user script manager, and during script auto update)", the browser and browser version need to be explicitly marked as working in the script, as what was current at the time of testing will not be a year later. |
Why? If I know something works in Greasemonkey but not Tampermonkey, I can show that on the script's page before users install and I can make that data searchable. In fact, even if the version information was made available in a "structured" way, I would probably just ignore it because it results in too many permutations of things (or at most, convert it into a sentence that could be covered by the "comments" section of the meta value). |
|
What use case(s) do you envision for this markup? Any compatibility assertions without version information is weak data that software can trust even less than whatever trust we have in the person who published the data, since it denotes a boolean data point X (high resolution data) about some fuzzy-matched grab bag of possible environments Y (ultra low resolution data) which it might include or not include. Claiming that a user script "works in Chrome" is a marketing lie that is perhaps true for 85% or even 100% of Chrome installations at the time the claim was made (and the current proposal doesn't even pin when that was), half a year later true for 74%, and a year later true for 5% of them. You can only know that your script is compatible with versions of user script engine already released, though you can make educated guesses it might work in versions you haven't tested too. It comes down to if you:
For 1) a compatibility note naming just a browser and user script engine is fine, and the signal is at best "if this thing I claimed to work doesn't work, please bug report and I might do something about it". For 2), you'd presumably have data on what browser and user script engine version this was tested to work with, which is more valuable for making stronger assertions in application UI:s about what data we have on compatibility of the script. An example of why version-less compatibility notes aren't great: for a long while, most Greasemonkey user scripts could be run in Google Chrome natively without fuss or an additional user script engine. Then one summer in Chrome 21, that feature was critically crippled UX-wise and put behind nasty flags, and any assertions about compatibility with a naked Chrome declared by a tag like this would be wrong. A tag saying If we do standardize a meta tag about compatibility, I think it would be neat if the values read from it would be less than a rumour or belief from some unknown person and time. Talking about versioned browsers and(/or?) user script engines strengthens the claim to something that can at least declare a compatibility map (when the compat landscape is a typical compat landscape), and which user script engines can in turn use to automatically warn about script upgrades marked as known incompatible with their current version. |
|
I quite agree with @johan because I still stubbornly wish to indicate opera 12 compatible, which means very different browser than chromium based opera (later versions). :) |
I envision this to be author-provided, just for them to easily denote (and for sites to display to users) what they know of compatibility, so # 1. 2 would be more like the rating/review system that Greasy Fork already has, though it doesn't have version info (yet). This is definitely a useful thing to have, but it's not what I'm suggesting. If/when we add this to Greasy Fork, I don't see feeding it into the script's meta block, either.
I agree that including version information would result in more specific data, but:
In short, specific data is specific, but it's useless if it's not going to be provided, displayed, or understood. If someone has a concrete use for the specific data, then maybe it can be part of the proposal, but Greasy Fork is not likely to use it. |
I think Opera 12 and Opera 15+ would be treated as completely different engines. |
I agree. I think most often it would be used to declare incompatibility with any version before X because a necessary feature or bug fix was implemented at X. Just like a minimum required version. Wouldn't that be really useful: a script stops updating because an old and now incompatible script engine is used. The engine can display a warning/information about the lack of further updates until the engine is updated... :)
That's the point. GF only knows the browser type and version via the user agent, but the script engine knows the complete environment. Therefore it can calculate or at least do an educated guess about the script compatibility if the version information is given, but without there is nothing reliable it can get out of this. If this tag is "only" made to replace all the "This is script is compatible with ..." statements at the GF script description page, then a version-less proposal indeed is preferable. |
What to do with this situation:
=> This would be four entries if I define everything with the version. If I define partial and write a comment only one entry. More versions / different browsers / different engines => more entries Second example:
=> user has engine v1 => update as there is no information on the engine v1 or don't update as there was a incompatibility with the version before? I'd assume that most script authors only test with the latest version of browser and engine and maybe add new information based on user input. So in my opinion it's more reliable to search if there is information on the engine and then show this information to the user instead of blocking updates completely. And for this there is no need for including versions. |
I don't say versions should be enforced, but IMO they should be allowed. If a new browser version is not compatible anymore it's most likely a bug that will be fixed. Otherwise (i.e Opera 12/15+) you can state it at the script header.
Why should one look at the history of the compatibility information? Script v2 and v3 contain and therefore only engine v2 will update script v1 to v3.
Maybe you're right for engine versions that were released in the past. But development is often more a process than a single event. Therefore scripts change and may require new features that are only present at newer engine versions. In this case everybody can use an old version of a script but only users with newer engines can use the most recent version. Example: GM 2.0 changes the way scripts can write values to unsafeWindow. If a script author doesn't want to clutter the source with engine version switches he can just add something like: Since no other GM version is mentioned at the script header everything below 2.0 is marked incompatible. |
But also engine v1 can update it as it's compatible again. And - if the author doesn't specify it explicitly, the user will not recieve an update. And that's not a good behaviour in my opinion.
But in real the script is only not tested in this version. It might work also in olde versions, but it was just not tested. So you will prevent updates again for a compatible version.
Also the browser version can influence if a script works or not => you also have to specify the browser. Additional you might update a script set with gm(2.0+) with gm 2.3 but in 2.3 there was a new feature / change introduced whcih causes scripts to break now. Take a script written before GM 2.0 for example. If it would have been possible to specify the compatibility version in a way like this (1.15+) all 2.0 engines would have updated and now the script is broken. To prevent this you have to specify each version explicitly. So for me using a version information to prevent updates is only possible if a script is marked incompatible especially for this specific version of the addon. Prevent an update just because it's not marked as compatible is a bad behaviour. And for me if a script specifies ff+gm as compatibility and I recognize it't not working I would see it as a bug (except if the author writes a comment that this addon is not officially supported.). Independent of the version of the addon where it was tested and the version I use now. If I know that the version number might prevent script updates then I would not use it as script author. To prevent from updating / installing another new tag would be more applicable where the author can specify a minimum and maximum addon version required for the script explicitly. But this would be another topic. |
No it can't! Script v2 and script v3 require engine v2, therefore engine v1 can't update the script to any version greater than v1.
So you can talk for every script author? The decision to use that feature should be their choice.
Why? The mentioned GM 2.0 change was backward incompatible. If the script adapts the new way of writing to unsafeWindow and script relies on that function then the script author can say for sure that GM versions lower than 2.0 are NOT supported anymore.
It doesn't matter if you blacklist versions lower than X or whitelist versions greater than X when every new script version can adapt that information to the most recent needs.
But isn't it up to the script author to decide about the compatibility. He can always mention no version at all or add gm(1.0+) to include all future engine versions. Nevertheless Tampermonkey would always only display a warning at the script installation page and also allow manually forced updates to versions with unknown compatibility. |
This feature was intended to say "It is tested with" and not "It should only be installed with" as far as I know. Because the author only specified that the script is compatible with a version does not mean it is incompatible with others. The author did not specify "script is not compatible with all other versions". He just specified that the script is compatible with a specific version and said nothing about any other version. So any other version has to treat it as unknown unless a specific incompatibility is specified.
No I can't. But: If you prevent updates for scripts with compatibility information for your engine based on the script compatibility and don't do this only if the version is explicitly marked as incompatible, you force any script author who want's to use a versioning to either test with any combination of engine and browser or to mark any combination of engine and browser as untested because otherwise the engine would prevent updates for his script users. So what I said later was that if you really want to use data to prevent engines from updates this should NOT be the same data that says "Hey, I tested it with" or "Hey it should work with" what I will use. And to say "tested with" or "should work with" does not need any version information as this information just blows up the necessary lines.
You can mock functions ... => if I want my script to be compatible in different Engines I might need to mock these functions and then it might work also in GM 1.15. But I didn't test it and so I don't write it as compatible. But with your interpretation of this information I have to test it and also include it in the compatible information to roll out the update to those users.
It does matter if I only want to show an information and don't prevent updates. Because what you want is preventing updates what I would give in a different keyword. So my suggestion would be to split this up. One thing is a keyword that has no influence on the engines; so it has only informational character and a second one like |
Ah OK, sorry if I misunderstood you. If that's the case then you're right, an engine cannot deduce anything about other versions. Chrome extensions are auto-updated and in normal there is no way back to an older version. So all you can get out of this is: most probably it will work with the recent Tampermonkey version because someone tested it with an older version.
If the version would be optional then your kind of script author can write anything without versions to express that his script is supposed to run at the the recent TM and GM version. No update will ever be blocked by TM unless the "chrome+tm" part disappears (and at least one My kind of script author can specify versions to express that too old TM versions are not compatible: And GreasyFork always interprets anything without versions.
Not necessarily. First, the old engine versions don't change anymore so they can only become incompatible by script modifications, right? With a little bit care you can keep a script compatible or at least you should notice if you make incompatible changes.
Sure, but if there is the possibility to define requirements then some might choose not to do so. For example TM also provides the functions that are necessary to write to unsafeWindow at GM 2.0+. Nice idea, but as you wrote the browser version might also need to be taken into account. |
Thats what I wanted to say. You can not get any information from this script version after a while as the script engines upgrade (and the browsers do also). So exclude this information (version) completely from the definition and don't do anything with it. Keep this information as informational like "I (don't) want to support X on Y and tested it". Then a user having problem can see that his engine is not supported and the script just worked before (=> it's likely that he will not get an update) or his engine is suported and the script does not work anymore (=> it's likely that he will get an update). If you want to prevent installation in specific engines / versions you should have a different keyword to have less confusion like "Why did it not update? I just said I tested it with X".
The example was about an incompatible change made on purpose which was reverted later. And with scripts with 2000 lines of code which are dependent and have requires it is not always possible to think of all changes made in older versions of an engine and if the script might be incompatible now. You have to test it to be sure. |
|
To get this moving again, I propose supporting version and user script compatibility info in such a way that it's easy to ignore for implementors who don't care, but can be defined by implementors who do. Here's the full proposal:
Here's a simple example: More complex example with an example descriptive info syntax inspired by @derjanb's comments: So if someone just cares about the browser, they can check to see what the browser info string starts with (or grab it up to the first punctuation) and use that. If you do care, grab the whole thing and parse it. I'm not defining a particular syntax for this section because I don't intend to use it; defining it can be done separately so it doesn't block the initial implementaiton. |
|
This has been implemented on Greasy Fork. Let me know your thoughts. |
|
Hi Jason, |
|
I don't understand why it didn't work there. I tried the same thing (though a webhook) and it worked. If you click for the most recent version of your script, you can it see working too - https://greasyfork.org/en/scripts/2334-mb-funkey-illustrated-records?version=41884. I wonder if I forgot to restart delayed_job after I made that change. That would mean the webhook code was running on the old code. |
|
OK so it means that it will work with my next version, then. |
|
Looks like it works on https://greasyfork.org/en/scripts/2375-mb-funkey-illustrated-records now. If anyone has problems or suggestions, please start a new issue. |
Let authors specific install methods/browsers, doesn't work/untested/works.
The text was updated successfully, but these errors were encountered: