Bugzilla

Callek asked me to comment on this wearing Balrog maintainer hat. A policy which could specify update-pin:60.* to stay on ESR60 might be quite workable, and fit with the idea that organisations only go through the big QA cycles for ESR branches. Balrog already offers the right release until we hit the X.2.0 release of a new ESR, but after that we'd need something new.

It looks like we support policies for regular releases too, and Kirk's scenario would be much harder to deal with. Balrog doesn't keep track of the latest 65.0 release, or the sequence of releases that we've offered which could be walked down until Balrog or Firefox finds the first one OK by the policy. Adding that kind of manifest approach would negate the ability to set rules to handle special situations (OS deprecation, issues with security suites etc). So my initial reaction isn't positive but I'll think on it some more, and would welcome more info on common use cases and background one why this would be useful.

Callek asked me to comment on this wearing Balrog maintainer hat. A policy which could specify update-pin:60.* to stay on ESR60 might be quite workable, and fit with the idea that organisations only go through the big QA cycles for ESR branches. Balrog already offers the right release until we hit the X.2.0 release of a new ESR, but after that we'd need something new.

It looks like we support policies for regular releases too, and Kirk's scenario would be much harder to deal with. Balrog doesn't keep track of the latest 65.0 release, or the sequence of releases that we've offered which could be walked down until Balrog or Firefox finds the first one OK by the policy. Adding that kind of manifest approach would negate the ability to set rules to handle special situations (OS deprecation, issues with security suites etc). So my initial reaction isn't positive but I'll think on it some more, and would welcome more info on common use cases and background on why this would be useful.