[Evergreen-general] [Evergreen-dev] Deploying Updated Hatch Chrome Extension

[Jeff Godin]

On Mon, Dec 2, 2024 at 11:55 AM Bill Erickson via Evergreen-dev <
evergreen-dev at list.evergreen-ils.org> wrote:

> Hi All,
>
> It's time to deploy an updated version of the Hatch Chrome extension.  See
> https://bugs.launchpad.net/evergreen/+bug/2076921.
>
> I'd like to do this as soon as possible since the extension is now being
> disabled in the wild for sites that do not have the
> "ExtensionManifestV2Availability" [1] setting enabled.
>
> The Google docs suggest the deployment can be done piecemeal, but I have
> yet to see the appropriate controls in the extension admin UI to configure
> that.  It's possible they will appear later in the process or that the docs
> I read were out of date.  Suffice to say, it may be all or none.  In any
> case, we can revert the deployment if needed.
>
> Before I make the change, though, I'd like to confirm that someone besides
> me has access to the Chrome store to manage the extension, in case we need
> to do an emergency revert and I'm not available.  I'm pretty sure Galen has
> access.  Any others?
>
> Any concerns or suggestions on timing?  It may take a few days for the
> update to be reviewed and rolled out by The Goog.
>

Hi, Bill!

My previous offer of help still stands, but no, I do not have access to the
Chrome Web Store Developer Dashboard for Hatch.

I believe phased / percent based rollouts are not an option for extensions
with fewer than 10,000 seven-day active users.

As for timing, avoiding Monday and Friday is good. To avoid some
unpredictability introduced by the variable Google review timeline, I'd
recommend NOT selecting the "Publish [Hatch] automatically after it has
passed review" option. This lets the review take place, then we can select
the date when the update is actually made available (up to 30 days after
the review is complete).

If there are problems, rollback can be done without needing a review
process (delay), and involves publishing the just-unpublished previous
version as a new version number. Any later fix to address whatever
regression necessitated the rollback would then need to be a new (higher)
version, and would need to go through the standard review process.

Rollback documentation points out that backward compatibility should be
considered before triggering a rollback. I don't think we have issues
there, but would appreciate a second set of eyes/brain on that aspect.

I do not know if rollback and Manifest V2 introduce any challenges at this
point. Best not to need to find out. :-)

Relevant docs:
https://developer.chrome.com/docs/webstore/update
https://developer.chrome.com/docs/webstore/rollback

-jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20241202/e1177ba6/attachment.htm>