Comment 6 for bug 1665102

Revision history for this message
Gustavo Niemeyer (niemeyer) wrote :

The current behavior was the precise outcome of a very long conversation we (Mark and I) had in Heidelberg, about the subtle properties of such updates. We agreed to block devmode => strict refreshes because we could not get a clear agreement on what was the proper way to treat those updates. Specifically, on refreshes that go from a snap that proposes devmode to one that proposes strict should it:

1. Refresh and keep the devmode flag on

or

2. Refresh and disable the devmode flag

I believe the more natural semantic is (1), given the flag meaning (development mode), while Mark would like to have behavior (2), taking the flag off. Behavior (2) doesn't seem sensible to me because it's an automatic and transparent change behind the developer's back which is changing the behavior of said snap for no apparent reason. It would also cause the strange effect that a devmode snap can be updated to strict, but cannot be updated _through_ strict (devmode => strict => devmode), even though the developer explicitly said this snap was in development mode before.

So, if we go with 1, sounds good to me. If the idea is 2, then I'd prefer to keep the current behavior as we originally discussed in Heidelberg.