That first command would temporarily slate all users for r3 and the following command would re-enable the progressive release with r4.
Is there a better way to do this? If not, would the same set of 10% of our users be pseudo-randomly chosen to take part in the progressive release?
Are there any other major downsides with this approach? I assume if snapd checked for updates between those two commands, it’s possible some users would transition from r2 to r3, but I’d expect that’d happen to very few of them if the commands were run back to back. Is this understanding correct?
I checked and in the scenario you describe that would be basically the best way to do it.
Since it’s a different revision I think a different set of users would be selected.
Right - actually, most of the users who were on r2 would move to r3, since the chance of the randomly-selected 10% for r2 and later, r4 overlapping is relatively small.
For what it’s worth, for our use case, it’d be really nice if it were possible to update r1 without randomly selecting another set of users to receive the progressive release. Essentially what we’re trying to do is to gradually transition our users to a new major version of our project with backwards incompatible changes. During this transition, it’s possible that we’d want to ship updates to the snap for the old major version (such as to update dependencies in response to security vulnerabilities), but this only seems possible if we’re OK with letting users randomly downgrade to the old major version which we’d also like to avoid.
