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 <[email protected]> wrote: > On Mon, Dec 2, 2024 at 11:55 AM Bill Erickson via Evergreen-dev < > [email protected]> 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 >
_______________________________________________ Evergreen-dev mailing list [email protected] http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
