Updates during progressive releases

[bmw]

Say I do a progressive release of a snap through commands like:

snapcraft release mysnap r1 stable
snapcraft release mysnap r2 stable --progressive 10

This would result in revision r1 of my snap being given to ~90% of users while r2 is given to the other ~10%.

Say that during this process, I discover a problem with r1. How can I update it?

As far as I can tell, the only thing I can do is something like:

snapcraft release mysnap r3 stable
snapcraft release mysnap r4 stable --progressive 10

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?

[roadmr]

Hi!

@bmw

As far as I can tell, the only thing I can do is something like:

snapcraft release mysnap r3 stable
snapcraft release mysnap r4 stable --progressive 10

I checked and in the scenario you describe that would be basically the best way to do it.

@bmw

would the same set of 10% of our users be pseudo-randomly chosen to take part in the progressive release?

Since it’s a different revision I think a different set of users would be selected.

@bmw

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?

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.

• Daniel

[bmw]

Thanks for all the info.

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.