Prevent a manifest from performing updates to the next major version (and stick to point releases)

[borque]

Hello
Mozilla is currently transitioning its Firefox ESR branch and Thunderbird to the next major release. This means that after a year of security and stability updates the versions will be upgraded from 102.x to 115.x.

As the focus of these releases is on stability, Mozilla will support both versions for about three months and trigger automatic updates with a later point release.
While it is preferable for new users to start with the new 115.x release now, it may be better for existing users to stay on the current 102 branch until 115.1 (or later) is released.

So my question is whether there is a switch in the current manifest scheme to prevent existing 102.12 installations from being upgraded to 115.0, thus favouring an update to the (formally lower versioned) 102.13, and only letting new users install 115.0.

Or is there another solution?

If not, my current plan is to provide only the 102.x manifests for a month or two, and then switch directly to 115.x after Mozilla triggers the automatic updates.

Thanks!

[mdanish-kh]

While I don't think there is a way to enforce this at the manifest level, it is possible at client side for users to set a gating pin to 102.x . This will make it so that they only receive upgrades from the 102.x release line.

winget pin add --id Mozilla.Thunderbird --version 102.*

[borque]

You are right, this is the correct client-side solution.
But since most users I know use rather simple commands like winget upgrade --all or winget upgrade XXX.yyy.

I wonder if a "no-automatic-upgrade-to-this-version-flag" for manifests might be a useful addition for a future revision?
Winget could then either not use these manifests for updates, but only for new installations, or at least display a warning that upgrading is not recommended.

[Trenly]

You can set requireExplicitUpgrade in the manifest which will cause --all to skip upgrades to the package but still allow users to upgrade by calling the ID directly.

Not sure if it works retroactively - i.e if a user already has 102 installed, not sure if it will apply; and also not sure if it works for just specific versions

[borque]

requireExplicitUpgrade looks like an interesting option for this. I have not found much documentation for it, so I assume, it‘ a boolean accepting only true or false as settings?!
Let‘s assume I offer two Mozilla.Firefox.ESR manifests, one for version 102.13.0 (without this switch) and one for version 115.0.1 with this switch set.
A new user using running winget install Mozilla.Firefox.ESR would get version 115.0.1?!
What about an existing user with 102.12.0 installed? Would he get the newer version 102.13.0, which does not have the „blocking switch“, without being asked, or would the even higher version 115.0.1 with the switch set interfere in some way?
And is there any difference between using winget upgrade —all and winget upgrade Mozilla.Firefox.ESRin this particular scenario?
As I said above, I have not found much documentation. So I am not sure what the behaviour of this switch is.

[Trenly]

Yes, it is a boolean. As I said, I don’t know exactly how it works with existing installs. Perhaps @florelis knows?