This commit disables get-released-versions comparison as our base branch (node-vN.x-nsolid-vX.x) isn't the same as Node.js (main). So, the check expects that we are running into the main branch where all release commits go to (so the changelog) is up to date.
Basically, there are two ways of solving it:
Disabling the workflow
Keep our default branch in sync with all release commits from old release lines. For instance, whenever v18 gets a new version, we need to cherry-pick it. Example: git cherry-pick e922fb64b53530af4ad2e3df298a302225645f5b. But, it seems annoying work for almost no gain (considering we never float a new API to Node.js modules).
So, I think the viable solution is just disabling the versions lint (Markdown and JS files will always work). This check is just to guarantee that the version specified in the API (e.g. added: v99.99) exists in the CHANGELOG.
This commit disables get-released-versions comparison as our base branch (node-vN.x-nsolid-vX.x) isn't the same as Node.js (main). So, the check expects that we are running into the
main
branch where all release commits go to (so the changelog) is up to date.Basically, there are two ways of solving it:
git cherry-pick e922fb64b53530af4ad2e3df298a302225645f5b
. But, it seems annoying work for almost no gain (considering we never float a new API to Node.js modules).So, I think the viable solution is just disabling the versions lint (Markdown and JS files will always work). This check is just to guarantee that the version specified in the API (e.g. added: v99.99) exists in the CHANGELOG.