Greasemonkey: Let server deliver a script which will never be (auto) updated

@updateURL about:blank + @downloadURL about:blank should do it (at least it was possible to deactivate auto updates using this in GM 3.x).

updateURL and downloadURL are not supported for 4.x.

In 3.x we just used the standard AOM controls for this.

In 4.x we don't have automatic updates at all yet, so we'll just have to include this as a base feature, once we do.

Would putting @downloadURL none align with what is planned for 4.x?

Oh I've just realized that you're saying you want the server that delivers the script to tell GM that it shouldn't update the script. (Whoops, didn't quite get to the end of the description ...)

There's no plans to ever read/use the value of any @...URL property in GM 4. I can't promise anything until update code finally gets written, but some sort of HTTP header feels better than trying to change the source of the script.

OTOH if TM supports a none value, there's always compatibility to consider.

The OP says:

The install URL includes a parameter indicating in the version.

From this, I assume that the query parameters are effectively permalinks to specific user scripts. It is also most likely that any auto-update / check-for-update functionality will use the internally saved downloadUrl (which is just the URL of initial install). With very minimal change, I believe we can support this form of permalinking by adding query parameter matching when detecting user scripts. Accomplished by adding *://*/*.user.js?* to the user-script-detect.run.js listener.

Oh I've just realized that you're saying you want the server that delivers the script to tell GM that it shouldn't update the script.

Yes, exactly.

some sort of HTTP header feels better than trying to change the source of the script

Greasy Fork stores the scripts in DB and rewrites the source anyway (e.g. generates a meta.js from a user.js). Changing the source is not a problem for me. HTTP headers may be a problem as the scripts may be going through caching software.

From this, I assume that the query parameters are effectively permalinks to specific user scripts.

In my parlance, the version parameter provides a permalink to a specific version of a specific user script.

I believe we can support this form of permalinking by adding query parameter matching when detecting user scripts.

Greasy Fork does not use URL parameters for any other purpose than linking to specific versions, but I can't promise it won't in the future, or that other sites don't either.

Upon further reflection: It would take more effort to be cross-engine compliant (@derjanb, @gera2ld), but: If we're going to let the source control update checking I'm thinking more along the lines of a new entry* such as:

// @updates never
// @updates 24h
// @updates 7d

Let the script specify how often it should be auto-updated. When I'm in active development I can keep it low, when I get stable I can tune it up (but back down if/when I start updating again). And a script host can (if they're going to be munging the script anyway) overwrite the value as they see fit (based on things like how many users have installed it, server resources, etc.).

I'd like a more descriptive name but don't have a specific candidate I like yet.

* Though for the never value, @downloadURL none support can be added also.

From the technical aspect, it should be sth. like @updatefrequency (too long?) or @updatecycle.
And hopefully, there will be a trigger to start a check of all scripts manually...

Let the script specify how often it should be auto-updated. When I'm in active development I can keep it low, when I get stable I can tune it up (but back down if/when I start updating again). And a script host can (if they're going to be munging the script anyway) overwrite the value as they see fit (based on things like how many users have installed it, server resources, etc.).

Sounds reasonable.

I'd like a more descriptive name but don't have a specific candidate I like yet.

Maybe @updateInterval?

or simply @updatetime... (not very exact, but catchy)

@updatetime makes me think of "at 8:00 am" rather than a frequency.

@Sxderp So you would support @updatefreq 1d?

I'm not a native speaker, but the value (i.e. 24h) is not really a frequency. It's an interval or a period, right? 🤓

@updateinterval 1day sounds good. I would recommend against "period" as it has an overloaded meaning in common english (even though it has a precise scientific meaning)

@updateinterval is as unprecise as @updatetime. You are not interested in the interval, but the (maximal) time span between updates...

I don't really like lapse, so my next suggestion would therefore be @updatespan 1d...

@arantius, when will automatic update be scheduled? I can not switch to 3.x in FF60.