Feature request: Finer-grain per-app upgrade policy

[CrendKing]

Currently, the only per-app upgrade policy is the hold option. It is a rough binary option. Sometimes I wish there are finer-grain controls over certain apps. For example,

1. Some apps are large, update daily (such as nightly version), rarely change anything I need. I wish to only update them on (bi-)weekly or monthly basis. Holding such app prevents me from updating them ever (could miss security updates that benefit me while I'm not aware).
2. Some apps are small, update rarely. I don't mind always update them. (This is current)
3. Some apps may break backward compatibility on major update, and I have scripts built around them. I don't mind update their minor changes, but I want to be informed before updating major changes.
4. If there are version control, I could imagine certain bucket be more concise and easy to maintain. For example, the java bucket have so many individual apps, only to differ versions, which follow semver.

Ideally, I want to put scoop update * in a daily scheduled task, and forget about it. If anything from 3 happens, it sends a notification so I can tend to it. Currently I have to evaluate scoop status result every time I run it, and the more apps I install the more I'd be careful.

I don't know much about how Scoop deals with versions. All I know are

1. App versions are "anisotropic". They have all sorts of different schemes.
2. Scoop manifest.json has the "autoupdate" section, which relies on extracting and comparing some version number for each app. Some rough (just $version), others are fine-grain ($matchVersion, $matchBuild).

I wonder if Scoop can provide a way to specify how an app should be automatically updated (scoop update *), that works for all apps, while still reasonable to end users. I can think of two approaches:

1. The easy way for Scoop to implement: expose the "internal" version variables to users to tinker. User is required to inspect manifest.json to figure out how the version numbers are extracted, following what pattern and set policy on them. If this is the way, probably only power users will ever use this feature.
2. The hard way for Scoop: provide only easily understandable rules to users ("only auto update minor versions", "weekly update"). Behind the scene, Scoop needs to categorize each app's version scheme ("app 1 follows semver", "app 2 is a nightly with date string as version") and apply the rules to each.

Is this ever going to be considered?

[CrendKing]

I find Cargo's document on dependency version policy good. Some other package managers also use a similar approach as this, such as npm.