fix: allow up to 4 integers in version

[viclai]

Details

As per the following docs, the version specified in the manifest can have up to 4 integers (separated by dots).

https://developer.chrome.com/docs/extensions/mv3/manifest/version/
https://developer.chrome.com/docs/extensions/mv3/manifest/minimum_chrome_version/

The schema currently only allows up to 3, so I updated the validation logic to allow up to 4.

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current PR for duplication.

[louisgv]

Thanks for the PR @viclai !

I think the main issue here is to fix the chrome allowed version and not so much the extension version. I would like to keep the manifest version format to adhere to semver, but let's incorporate your fix for the chrome version!

[viclai]

@louisgv, I actually opened this pull request in hopes of being able to have the flexibility to specify a fourth integer in the version specified for my Chrome extension (i.e. version), so the minimum Chrome version (i.e. minimum_chrome_version) is actually less important for my use case. Is there a reason why we want to adhere to semantic versioning? Is it possible to stick to the semantic versioning spec for the package.json, but still allow the extension version to be specified using up to 4 integers?

[louisgv]

@viclai interesting - what's your use case for the 4th number in the version? I suppose we can lessen the restriction on this since it wouldn't change the behavior of our bundler. Just wanted to be aware of the reasoning :D

[viclai]

@louisgv, we're thinking about using the 4th number to differentiate versions for builds that we distribute internally (before uploading and publishing to the Chrome web store). Our ideal workflow is somewhat similar to what is mentioned about release candidates in the following link.

https://www.chromium.org/developers/version-numbers/

[louisgv]

we're thinking about using the 4th number to differentiate versions for builds that we distribute internally (before uploading and publishing to the Chrome web store). Our ideal workflow is somewhat similar to what is mentioned about release candidates in the following link.

Hmm... Actually, I'd recommend sticking to semver if that is the case. The released version should track the code change and the release build. If there was some patch released internally, simply bump the patch number. And then, when it's time to release to the public, bump the patch again (or the minor) - the latest version number would contain the diff from the last to the latest. Each version should represent a new build (internal or external) for your extension anyway, so why not keep it linear.

To differentiate the naming/env of the version, use the version_name field in your manifest override.

The key reason I'm against diverting from semver is that, based on my exp, 3 numbers are more than enough for tracking code-build. Adding another number leads to miscommunication or process bypassing.

For my extension, I bump minor when I release to chrome store. Otherwise for local test and Itero I just have the patch version rolling with my commit/push.

RE: internal extension - check out Itero if you haven't - we integrate with GitHub and automatically bump patch for each push to a staging branch so you can continuously test with your team (esp for stakeholders who don't need to worry about the code). Docs: https://docs.plasmo.com/itero

[viclai]

Hmm... Actually, I'd recommend sticking to semver if that is the case. The released version should track the code change and the release build. If there was some patch released internally, simply bump the patch number. And then, when it's time to release to the public, bump the patch again (or the minor) - the latest version number would contain the diff from the last to the latest. Each version should represent a new build (internal or external) for your extension anyway, so why not keep it linear.

To differentiate the naming/env of the version, use the version_name field in your manifest override.

The key reason I'm against diverting from semver is that, based on my exp, 3 numbers are more than enough for tracking code-build. Adding another number leads to miscommunication or process bypassing.

For my extension, I bump minor when I release to chrome store. Otherwise for local test and Itero I just have the patch version rolling with my commit/push.

@louisgv, those are fair points! We haven't necessarily settled on a good convention for how we want to bump the extension version in our continuous workflow, but I was just wondering if we can support this level of flexibility (in case we want to use it later). We actually are currently using the version_name field like you mentioned!

With all that being said, I'm happy to make this fix for just minimum_chrome_version (if that part is still reasonable) while I have this PR open. Otherwise, I can just close this pull request.

RE: internal extension - check out Itero if you haven't - we integrate with GitHub and automatically bump patch for each push to a staging branch so you can continuously test with your team (esp for stakeholders who don't need to worry about the code). Docs: https://docs.plasmo.com/itero

This might be a separate conversation, but I'd be interested to see a demo before we commit/subscribe to Itero. 😄

[louisgv]

With all that being said, I'm happy to make this fix for just minimum_chrome_version (if that part is still reasonable) while I have this PR open. Otherwise, I can just close this pull request.

Let's have this PR handle the minimum_chrome_version! - I think we can split that version checking code into validateSemver vs validateBrowserVersion

[louisgv]

Seasoned and ready to be served 👨‍🍳