Bugzilla

(In reply to John Bieling (:TbSync) from comment #12)
> Let us consider a Company, which is using Firefox 68 ESR and has finished their testing for Firefox 78 ESR only after Firefox 91 ESR has been released. They change the pin policy to 78 and nothing happens. Their instances do not update. I would not consider this a failure of the pin policy. To overcome this, they can manually deploy Firefox 78 ESR.

This sounds dangerous to me. Consider this scenario:

 1. Pin policy updated to ESR78 while that is the newest version.
 2. A week later, ESR91 is released.

Most machines would update during that week. But some machines would be loaners or would belong to be people on vacation and would not get updated. Now those machines are unable to update until the update pin is moved again.

In the best case, the enterprise is aware of this problem and has a mechanism for deploying the newest Firefox version to machines that need it. In this case, what did they gain from the pinning policy? What is the purpose of an update mechanism that requires that you also have your own, independent update mechanism? It seems to me that they would be served equally well by simply [disabling update altogether](https://github.com/mozilla/policy-templates/#disableappupdate).

In the worst case, the pinning policy effectively hides the problem from the enterprise. Some installations are out of date. Especially infrequently used machines may never be updated again.

(In reply to John Bieling (:TbSync) from comment #12)
> Let us consider a Company, which is using Firefox 68 ESR and has finished their testing for Firefox 78 ESR only after Firefox 91 ESR has been released. They change the pin policy to 78 and nothing happens. Their instances do not update. I would not consider this a failure of the pin policy. To overcome this, they can manually deploy Firefox 78 ESR.

This sounds dangerous to me. Consider this scenario:

 1. Pin policy updated to ESR78 while that is the newest version.
 2. A week later, ESR91 is released.

Most machines would update during that week. But some machines would be loaners or would belong to people on vacation and would not get updated. Now those machines are unable to update until the update pin is moved again.

In the best case, the enterprise is aware of this problem and has a mechanism for deploying the newest Firefox version to machines that need it. In this case, what did they gain from the pinning policy? What is the purpose of an update mechanism that requires that you also have your own, independent update mechanism? It seems to me that they would be served equally well by simply [disabling update altogether](https://github.com/mozilla/policy-templates/#disableappupdate).

In the worst case, the pinning policy effectively hides the problem from the enterprise. Some installations are out of date. Especially infrequently used machines may never be updated again.