Versioning and releasing large Chrome extensions

[Dave Stewart]

Hey all,

I recently overhauled my extension versioning scheme after struggling with naming and tagging since its inception.

I write about it here if anyone is interested / has the same issues:

https://davestewart.co.uk/blog/extension-versioning/

I'm also interested in feedback if anyone thinks it's tosh! 😆

Cheers,

Dave

[Oliver Dunk]

Hey Dave,

Thanks for sharing this - it was a really great writeup!

The general approach you settled on of "version indicates which features are inside" feels like it lines up pretty closely to what I've done in the past and seen work well. I think that's a pretty good thing to settle on.

One thing that you might be interested to know and could be good to call out in a blog post about versioning is that we strip leading zeros (so surprisingly, 1.01 is actually the same as 1.1). I don't think this changes anything you wrote but it's a definite strange part of how things behave. There's a bug open here and it's something I think we should fix, although doing that and making sure it isn't a breaking change might be tough.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/af918599-6684-4d21-a42e-6f57e077f9abn%40chromium.org.

[Dave Stewart]

Hey Oliver,

Thanks so much for the kind words! It means a lot 🤗

I just tested that and, yes, they get stripped. I thought from memory that leading zeros got rejected from the web store (I don't have any in my releases) but I guess if it's a breaking change, then perhaps not?

Anway. Thanks again!

[Oliver Dunk]

I just did a very quick test, and it seems like you can submit those. I wouldn't recommend it though!

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Erek Speed]

Thanks for sharing Dave, I think it's definitely a good topic to write about.

My case was simpler as my changes are incremental enough that I've never used alphas or betas but I've got Semver working okay in my build pipeline.

Because I rely on Semantic Releases to automate the tagging and uploading of my package, semver is required but I'm not too bothered by it. My pattern is as follows:

Major:  Breaking change- I needed to increment the required version of Chrome in my manifest.
Minor:  Any kind of user experience enhancement.
Patch:  A bug fix or data update.

There are gaps but luckily my use cases avoid them.

Cheers,
Erek

2023年8月9日(水) 20:06 'Oliver Dunk' via Chromium Extensions <chromium-...@chromium.org>:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAOsQqBnVpVAGJhrQJs3A4a3brwU_JxRf9BKKmiWJ%3DRFKMN4nSQ%40mail.gmail.com.

[Dave Stewart]

You raise a great point around automated releases!

It's something is something I didn't cover – mainly because I don't use them myself – but am aware of (and suffer developer guilt for not being up to speed on them!).

I have a new (tiny) extension project in the offing; perhaps I'll jump in and try it on for size to get a feel for the automation 👍

Thanks! 🙏

[Gaurang Tandon]

Thanks for sharing the interesting article Dave.

You noted that "I was building a product not a library; fixating on how to satisfy these library-oriented constraints was the cause of my product-versioning woes:" 

I will add that with libraries, it is quite common to install old versions (for example, to use a compatible library version for your current framework). npm, pypi, etc. allow you to download older package versions. However, with Chrome extensions, there is only one supported version and that is the latest version (older versions are not even listed!). Therefore, it has a totally different way to think.

I will also add another way to do versioning, which is to increment:

1. minor version for every public (prod) release,

2. patch version for every private (beta) release, an

3. build version for each internal (alpha version for the colleagues) release.

Thanks to this, whenever you see a new version number in your analytics/error logs, you would know what release channel it corresponds to. For example: 2.8.0.0? That must be a public release. 2.8.1.2? That is a alpha release. 2.8.1.0? That is a beta release. 

So, in this way, instead of using numbers to focus on the severity of the change, you can use it to indicate the release channel.

Best,
Gaurang

[Dave Stewart]

Hey Gaurang!

Thanks for the comments, and also for another way to slice and dice version numbers.

Have had some great feedback here; I think I will go ahead and add it to the article in the "final thoughts" section.

Thank you! 🙏