Create IMAGE extension beta in chrome web store

[jeffbl]

We'd like to give new versions of the extension to beta testers (or even members of the IMAGE team!) without requiring the annoying step of unpacking a .zip file and manually loading it into the browser. It would be great if like with mobile app stores, we could just have a separate "beta" version under the same entry as the production extension, but this is not possible. The sanctioned way to do this is apparently to have a completely separate entry with some specific naming requirements:

https://developer.chrome.com/docs/webstore/cws-dashboard-distribution/#publishing-a-test-version

We should create such an entry, making sure to follow the above requirements. We should push new versions to the new beta entry for panel testing, and/or internal testing. Normally, I'd say we should push to this BETA version:

• whenever we have a push to the non-beta version (or at least update it to latest non-beta version + any changes, so that the underlying support stays in sync)
• whenever we want testers/internal folks to be using a specific version for user testing, or for testing before push to production.
• Other cases?

I was thinking maybe it should by default run against unicorn, but I think this is a bad idea given that unicorn is normally less stable and less capable. @JRegimbal any thoughts? Even if we don't typically enable it, It might be nice to be able to specify the default server easily, however, so that we could make breaking changes and run unicorn on a new version to be compatible with a beta extension version?

[JRegimbal]

I worry a little bit about having the default be to have changes both in the server and extension. If people use Unicorn so heavily though, maybe it should be an actual option in the extension (or at least the beta version) rather than something that needs to be manually input?

[jeffbl]

Options:

1. Have the beta always hard-coded to use unicorn by default. I think this will backfire since sometimes we'll be pushing a beta with just extension UI changes, and want testers to use it against production server.
2. Decide each time we build the beta extension which server we'd like it to work against by default.
3. Have another radio button "unicorn" in the beta extension only. (HIstorical note: we used to have this in the production version!)
4. Have a "min server version" requirement in the extension. If pegasus doesn't meet that, automatically go to unicorn. (Not generic for anyone else building a server, and would create inscrutable bugs if someone didn't know they were being kicked to unicorn!)

I think 2 and 3 are the safest and most useful...

[JRegimbal]

I'd lean towards option 3 myself. I can't remember why we dropped this in production though!

[jeffbl]

Because it was weird to have hardcoded McGill servers in the options, rather than a generic typein field. I'm open to debate on including both, at least until we know of other servers running...

[jeffbl]

@Cybernide thoughts on the above discussion, and timeframe for this? It is primarily to help make testing easier, including with the panel, or even formal user studies. If not helpful, we can postpone or "don't fix", but I still think this would help us try things out more easily.

[Cybernide]

Concur with Juliette. 2 sounds like there's the potential for trouble if we ever forget. 3 is probably the best call. I am unable to publish the test extension because it still uses manifest V2 and they're no longer accepting new extensions that use the old manifest version.

[jeffbl]

Ah, right. Well, I guess that means we'll first use it for our manifest V3 testing! Moved to that milestone, on assumption it will come in sooner once @jaydeepsingh25 has an early build to test. This will be a great test case for doing this, since we're going to want most of the team to be testing the new extension.

[jeffbl]

One other thought: Is it possible to have both production and beta extensions loaded at the same time? This would be very handy for comparing. Either way, @Cybernide, I suggest renaming the context menu item to Get IMAGE Rendering (beta) or something, so that it is very clear which one is being used. Otherwise I also fear I'll foget which one I have installed, and log bugs against the wrong extension...

[Cybernide]

It is definitely possible to have two extensions going at the same time. I was going to say, before I even read the end of your post, we'll need to rename the context menu item as it gets confusing!

[Cybernide]

The extension beta is up and running! We have TWO versions of IMAGE! Closing @jeffbl