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

[Bill Erickson]

Hi,

If there are no objections, I'll update the extension this week with the
Publish-Automatically option disabled.  If all is well, I'll officially
publish the new version next Tuesday (Dec 17th) morning.

Thanks for all of the assistance,

-b


On Mon, Dec 2, 2024 at 12:18 PM Jeff Godin <jgodin at tadl.org> wrote:

> 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/20241210/d3bdbb75/attachment.htm>