Greasy Fork Feedback
[RESOLVED] Incorrect @version in .user.js#userscript #metadatahttps://greasyfork.org/scripts/10/code -> version 7.5 (as I posted)https://greasyfork.org/scripts/10/code.user.js? -> version 1.20140303163054editTurned out, all my scripts' versions are changed!
The site will rewrite some of the meta in the script provided by the author when users install it. One of the things it will do is handle the version by putting one based on a timestamp. The alternatives would be to let the author put whatever they like as the version (which could mess with updates if they kept the version the same or went backwards) or have the site validate that the version incremented when the code changes. I thought having the site do it itself would remove an annoyance, but if people want to handle the version number themselves I'm willing to change it.
Perhaps generate .meta.js like USO doese.g. https://userscripts.org/scripts/source/162010.meta.jsSee https://github.com/greasemonkey/greasemonkey/issues/1885
Like USO in what way?
*nimbrung yes,.I think providing meta api and what realy happen here is something quite different.This is just my opinion,.I dont know why you have to rewrite the version meta in the script, which previously documented here http://wiki.greasespot.net/Metadata_Block.Why dont just make another one? And suggest us not bother to use/modify it, coz somehow you'll validate when it goes wrong.Some or maybe a lot of script out there have high dependence on this, let say when it has self check for an update, this behaviour then helped by ".meta.js" to not suck the whole script.And in the other side version meta is more like label for author, coz it always appear in most extension/addons like Greasemonkey/Tampermonkey after the script name it self,. timestamp is kinda ugly and not human-friendly imo o_O"That's all.ouw and btw, i like the idea if it'll automate with timestamp meta anyway, cut my effort to (new Date).getTime() everytime i commit :)
As I understand it, @version is what Greasemonkey is reading to know when a script has updated, so it's important that when the code is updated, @version is updated too, otherwise Greasemonkey won't update. I thought that the site handling @version automatically would be the easiest solution, but if what you're telling me is @version is meaningful and important for authors, then instead I can just force the user to update @version if the code has changed at all.
The metadata of a script should never be modified from what the author intends if at all possible, especially in the case of debugging (e.g. "What version are you using, user?"). I would rather throw up a warning that the version wasn't incremented, but still allow the user to upload the script. In the case of non-existent @version keys, that should be the only time you should add one on your end.For the meta.js routine (serving just the script metadata), keep in mind that you can handle this by checking the `Accept` header that GM implemented recently: https://github.com/greasemonkey/greasemonkey/issues/1824
OK, that's sensible for version. Filed.The other metadata that's currently rewritten are namespace, updateURL, installURL, and downloadURL. I imagine the -URLs are OK to add/rewrite... What about namespace? This says "The combination of namespace and name is the unique identifier for a Greasemonkey script. If a script is being installed, and a script with that same name and namespace already exists, it will be replaced by the new script.". Is this just on install and not an update? Is there a danger that someone can reuse an existing's script name and namespace to wipe it out on the user's machine?I'm not sure what the purpose of that new header would be for this... can you explain?
Yes there is always a chance someone could use the same @name and @namespace, but it would only wipe out on new install. GM prevents updates installing over a current script (https://github.com/greasemonkey/greasemonkey/blob/838f5b7da8a9ce5444efbc13a3758adeb35dd3fc/modules/script.js#L537-554). I don't think this is a big concern.If an author defines a @key, it should never be overwritten or modified. If it doesn't exist, then I think it would be OK to add it, but I would limit those you add to @namespace and @version. @name should always be there, but if not I wouldn't even allow it--error in that case.The "Accept" header would eliminate the need for you to define the @*URL keys as you can check to see if GM is asking for meta or not. If it is, you could automatically serve just the meta. If not, serve the full script.
Thanks a lot for the info. I understood the meta documentation to say that @installURL and @updateURL are the only way to enable updates because there's nothing that says anything else about updates. I just went and filed a ticket against GM to get the update process documented. I've got a few more questions that I put in there and I'll fix this all up soon.Greasy Fork saves the author's code as submitted so I can just regenerate once I update the logic.
The author's @version will now be retained, but the site will validate that it increased if the code changed. The author can choose to update anyway.
Sign in to post a reply.