v7.31.0 introduced a breaking change by dropping support for Node.js v14

[cpcallen]

Background

Dependabot is trying to update webdriverio from 8.3.11 to 8.8.6 in Blockly but this is causing several tests that use webdriverio to fail when tests are run on Node.js 14 with the error message:

SyntaxError: Unexpected token '||='
    at Loader.moduleStrategy (internal/modules/esm/translators.js:145:18)

It turns out that the entire 8.x series has always required Node.js >= 16, but it wasn't until somewhere between 8.3.11 and 8.8.6 that any actual incompatibilities were introduced, so, uh… thanks for supporting v14 a lot longer than you claimed to, I guess!

Breaking change in v7.31.0

However, in the process of figuring this out, I notice that webdriverio v7.31.0 (and presumably other packages in the same release) also dropped support for Node.js v14, which would appear to be a breaking change.

I can think of threefour possible explanations:

• webdriverio does not use semantic versioning.
• Dropping support for older versions of Node.js is not considered a breaking change—despite v14 remaining in LTS for two more days as of this writing.
• This was simply an error.
• I have overlooked something.

I was going to file a bug about this incident but I'm not sure which of the above is the actual mistake.

[christian-bromann]

• webdriverio does not use semantic versioning.

We do.

• Dropping support for older versions of Node.js is not considered a breaking change—despite v14 remaining in LTS for two more days as of this writing.

Node v14 should still be support for WebdriverIO v7.x, if not we consider it a bug.

• This was simply an error.

I assume.

I am very confused about the git range between v7.30.3 and v7.31.0 - it shows over thousands of commits while there shouldn't. If I check the commits made between these versions it is only some patches and mostly dependabot updates.

[cpcallen]

I am very confused about the git range between v7.30.3 and v7.31.0 - it shows over thousands of commits while there shouldn't. If I check the commits made between these versions it is only some patches and mostly dependabot updates.

After looking at this a bit more I discovered that the problem is simply that the v7.30.0 tag is actually applied to the release commit for v8.8.4 (e88a296) instead of to the one for v7.30.0 (1e3f2b5) which quite sensibly is the parent for the release commit for v7.30.1 (9fdf0b6, which is actually tagged v7.31.1).

So it looks like the tag was wrong. What about the actual package contents? Checking npmjs.com it looks like 7.31.0 was not in fact ever actually published.

So: something went wrong with the .0 release and the fix was to release it as .1.

So it looks like there is not in fact an error needing fixing here (other than maybe to figure out why the .0 release went wrong so that similar incidents can be avoided in future).

[christian-bromann]

Great investigation. I remember releasing v7.30.0 with latest tag which was not intentional. After this I immediately released v7.30.1 with a v7 NPM tag and a new v8 version as latest. I was not expecting this to become an issue for someone. One way to prevent this from happening again is to include a step in the release pipeline to verify that latest releases can only be done in the main branch. I will look into what is the best way to achieve this. Thank you for looking into this.