feat: align semantic version with manifest version

[owlcode]

Pull Request

Related issue

#111 - Allow publishing of pre-release version

Description

Parse pre release version and make it compatible with extension's version field inside manifest. Use version_name field from chrome extension manifest to exactly reflect version.

This is slightly different approach compared to #112

Why

Chrome web api call throws a version format error when trying to publish a package from pre-release branch.

How

Parse prerelease version number and align it with chrome extension requirements. For example if next version is 1.0.0-develop.1 it will format it as 1.0.0.1

Screenshots

How has this been tested

Unit tests

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• Documentation
• Ready to be merged
• My code follows the code style of this project (run npm run ci to be sure).
• I have read the CONTRIBUTING document.

[RupertBarrow]

Hi @owlcode , I developed this same feature in my fork.
To make this work for any channel (develop, alpha, beta), generating "1.0.0.1" from "1.0.0-develop.1" is not sufficient because it would conflict with "1.0.0-alpha.1" and "1.0.0-beta.1", for example.

Since the "version" manifest property is not displayed once the "version_name" property is used, I ended up by generating "1.0.0." in the "version" property, timestamp being Date.now in milliseconds which is unique and incremental. This solves all other questions.

You may update your PR with this idea, so that contributing my PR does not collide with your work.

[owlcode]

@RupertBarrow I saw your fork and would have probably used it but haven't found NPM released package.

I am not entirely sure if we need allowPrerelease flag or can this change can be considered a fix.

I get your point of having conflicting version when using different prerelease channels but with your approach you can fall into collision too when two different pipelines are running concurrently (although I realize it's much less likely). It's not a problem for me since I've different extension ids on separate channels. I chose to have some reference to initial version number but I think I'd agree it doesn't really matter since we have version_name

[RupertBarrow]

I saw your fork and would have probably used it but haven't found NPM released package.

I use a private NPM registry on Github. Would it be useful to make it public ?

It's not a problem for me since I've different extension ids on separate channels.

Yes, I must do that too.

I chose to have some reference to initial version number but I think I'd agree it doesn't really matter since we have version_name

I was worried about how Google managed the version field internally, especially if there are duplicate version numbers on different channels

[owlcode]

I use a private NPM registry on Github. Would it be useful to make it public ?

As of now not for me since I've already published it under @owlcode/semantic-release-chrome

I was worried about how Google managed the version field internally, especially if there are duplicate version numbers on different channels

Considering what Google recommends for test releases (I mean different extension id) then I guess having duplicate version numbers on different channels is not a problem? I don't think releasing same extension id from different branches would make sense to anyone?

[envil]

Since the "version" manifest property is not displayed once the "version_name" property is used, I ended up by generating "1.0.0." in the "version" property, timestamp being Date.now in milliseconds which is unique and incremental. This solves all other questions.

Oh I didn't know that having number this large is acceptable because the documentation says that it's much smaller than that: https://developer.chrome.com/docs/extensions/reference/manifest/version

[RupertBarrow]

Oh I didn't know that having number this large is acceptable because the documentation says that it's much smaller than that: developer.chrome.com/docs/extensions/reference/manifest/version

You're right, I had to truncate it.

[envil]

Oh I didn't know that having number this large is acceptable because the documentation says that it's much smaller than that: developer.chrome.com/docs/extensions/reference/manifest/version

You're right, I had to truncate it.

So it means that each release cannot be less than 100k seconds from each other?