Staged rollout to 5% — Can we hotfix the previous version without breaking the rollout?

[Morgan BRUNOT]

We're planning to roll out a major update (v5.0.0) of our Chrome extension to 5% of existing users via the
  Chrome Web Store partial deployment feature. Our current production version is v4.2.16.

  We want to understand the disaster recovery scenario: if a critical bug is found in v4.2.16 while v5.0.0 is
  rolling out to 5%, can we publish a hotfix (v4.2.17) to the 95% of users still on v4.2.16 — without affecting
  the 5% already on v5.0.0?

  From our reading of the documentation, it seems this is not possible because:
  1. The Chrome Web Store requires each new version to have a strictly higher version number — so v4.2.17 would
  be rejected after v5.0.0 is submitted
  2. Publishing any new version cancels the in-progress staged rollout
  3. There is no way to run two parallel update tracks

  This means our only options appear to be:
  - Rollback v5.0.0 entirely (losing the staged rollout), then publish the fix
  - Forward-fix by publishing v5.0.1 (which kills the v5.0.0 rollout and pushes everyone to v5)

  Questions for the community:
  1. Can anyone confirm this understanding is correct?
  2. Has anyone found a workaround to patch the "non-rollout" population independently?
  3. Are there best practices for managing staged rollouts when the previous version might need urgent patches?

  Thanks in advance for any insights.

[Simeon Vincent]

1. Can anyone confirm this understanding is correct?

You're correct that you cannot publish a version with a lower version number. If you wanted to publish an update to v4.2.16, it would have to use a larger version number than v5.0.0.

One option here might be to deply the hotfix (what you described as v4.2.17) as a sub-version of the v5 line. For example, v5.0.2.17. That would allow you to continue to use the v5.X line for the rollout after getting the hotfix out.

2. Has anyone found a workaround to patch the "non-rollout" population independently?

The most direct workaround is to use a separate extension as a test or early release channel. For example, if you had ACME Extension (Stable) v4.2.16 you could have a separate extension called ACME Extension (Experimental) where you push out v5.0.0. Once you verify that the Experimental channel is stable, you can "promote" it to the Stable release by going through the normal version deployment process with your main extension. See Publish a beta testing version for additional details. You can also use different visibility settings on the pre-release version to limit access to a set of email addresses or a Google Group. CWS also recently announced the abiliyt to share a private extension with an enterprise.

3. Are there best practices for managing staged rollouts when the previous version might need urgent patches?

The #1 thing I'd suggest here is using multiple extensions as separate release channels as described in my previous comment. Other than that, the main thing I'd call out is that there's no way to target which segment of your extension's userbase will receive an update. The closest thing you can do is deploy the new version at 100% rollout to try to ensure that everyone picks up the change. 

Simeon - @dotproto

incremental.software

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/43ebdb32-3a62-442a-92f8-f24b7d411077n%40chromium.org.

[Simeon Vincent]

Oooops, I hit send too early.

This means our only options appear to be:
- Rollback v5.0.0 entirely (losing the staged rollout), then publish the fix

Unfortuantely that's not how rollback works.

CWS's rollback feature still requires that the next version have a higher version number. Rollback works by assigning a previously-published version a new, higher version number and immediately deploying it. Before this feature was introduced, developers could go through the same process manually, but doing so required that the new submission go through the standard review process. Since previous versions have already gone through the review process, the rollback feature allows CWS to skip the review step.

Simeon - @dotproto

incremental.software