search

GabeDuarteM / semantic-release-chrome

Set of semantic-release plugins for publishing a Chrome extension release
https://www.npmjs.com/package/semantic-release-chrome
MIT License
43 stars 16 forks source link

feat: align semantic version with manifest version #113

Open owlcode opened 6 months ago

owlcode commented 6 months ago

Pull Request

Related issue

https://github.com/GabeDuarteM/semantic-release-chrome/issues/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 https://github.com/GabeDuarteM/semantic-release-chrome/pull/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

Checklist

RupertBarrow commented 6 months ago

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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?