Maintenance branch release (v7.4.0)

[goosewobbler]

• backporting
• prerelease
• manual test
• release
• release notes

[goosewobbler]

I couldn't get turbo-version to use 7.4.0-next.3 for some reason, so we're doing pre-release testing with 7.5.0-next.0. The pre-release doesn't pass E2Es in wdio-electron-service-example. The error is:

Error: Cannot find module '<snip>/node_modules/@wdio/electron-utils/dist/cjs/log.js'

[mato533]

May I ask what the job is? I want to check the log.

[goosewobbler]

The prerelease of 7.5.0-next.0 is this one: https://github.com/webdriverio-community/wdio-electron-service/actions/runs/13320547465/job/37204233512

I'm guessing that there's something which should have been backported which wasn't.

[goosewobbler]

Here's the log for the failed 7.4.0-next.2 release, in case you meant that: https://github.com/webdriverio-community/wdio-electron-service/actions/runs/13320347399/job/37203675227

[mato533]

@goosewobbler
Only utils of v7.5.0-next.0 was published at 3 month ago...
Another package(service, type,bundler) was released within 24 hours.

https://www.npmjs.com/package/@wdio/electron-utils/v/7.5.0-next.0

It seems to be well if we release v7.5.0-next.1 or upper version..

[goosewobbler]

Ah that would be it, I think this was when I was testing turbo-build release.

[goosewobbler]

The manual E2Es pass now. I think turbo-version might have been getting the version from the existing git tags, I deleted all the 7.5.0 and 7.4.0 prerelease tags, let's see

[goosewobbler]

Fixed it, we have 7.4.0-next.0 now

And some more errors, fixed one of them, getting this old friend. I updated wdio-electron-service-example

[0-0] Error in "showOpenDialog with complex object.should be mocked"
Error: expect(electron.dialog.showOpenDialog).toHaveBeenCalledTimes(expected)

Expected number of calls: 1
Received number of calls: 0
    at Context.<anonymous> (/Users/sam/Workspace/wdio-electron-service-example/test/api.spec.ts:793:32)

[goosewobbler]

Actually I think this is due to the old packages released on NPM as 7.4.0-next.0. Given that the 7.5.0-next.0 manual test worked, I'm going to do the full release anyway, and follow up if necessary

[goosewobbler]

Now we have issues with the NPM publish of the release workflow.

Progress: resolved 29, reused 5, downloaded 0, added 5, done
Publishing wdio-electron-service... pnpm publish -r --access public --no-git-checks --tag v7
npm error Tag name must not be a valid SemVer range: v7
npm error A complete log of this run can be found in: /home/runner/.npm/_logs/2025-02-14T16_57_59_884Z-debug-0.log

[goosewobbler]

I think we need the tag for the pre-release workflow to be maintenance-next when the source branch is not main. And maintenance for the release workflow when the source branch is not main.

Or maybe lts / lts-next.

@mato533 what do you think?

I resetted the v7 versions and deleted the git tags so that we can release once the NPM tags are being set correctly, will look at this later.

[mato533]

thank you live update!

I like lts / lts-next
because it is very simple.

[goosewobbler]

@mato533 I've been thinking about the development flow here and if we're going to support a maintenance branch then it makes sense to separate things further and have a 'current' or 'stable' branch as well, the issue is that currently main is being used for breaking changes / v9 dev - once we merge those, we lose the ability to release on v8.x. The other issue is that the LTS / maintenance release is actually getting every non-breaking change, I think it makes more sense to stick to only security / bug fixes.

e.g. for the current versions:

• main: Future development (v9 prerelease)

  • All new features start here
  • Breaking changes allowed

• v8.x: Current Stable

  • Bug fixes
  • Minor features
  • No breaking changes

• v7.x: LTS

  • Security fixes only
  • Critical bug fixes
  • Minimal changes

What do you think?

I propose we sort out this approach before merging any v9 breaking changes to main...

[mato533]

@goosewobbler
Thank you for sharing your consideration.

My concern is same as you written.
In particular, the following comments are the reason why, when I was developing v9 features, I created a separate branch ta/cdp/main and tried to delay merging into main as much as possible, and also avoided Breaking Changes as much as possible.

once we merge those, we lose the ability to release on v8.x.

Basically I agree to create 3 branches main(for v9),stable(for v8.x), lts(for v7). And also I agree about kind of changes to be applied. The changes reflected in the current backport work may be too many😅.
If I were wondering, what the higher level project (WebdriverIO) is doing, but I have not found any solid documentation so far.

[mato533]

It may be a good idea to use stable as the main branch.This is because I believe that most development does not involve breaking change.

However, my concern is to operate feature and stable separately, so when we release feature, We may merge it with stable, but it may be difficult to resolve conflicts at that time.The longer we run it, the more likely it will be.

[goosewobbler]

Yeah, I think you're right. Keeping main stable and operating a feature branch approach with some level of automated sync makes sense, I'll get some PR(s) ready for this.

[mato533]

I like the simplicity of operation and flexibility that the project employs. Any idea that doesn't lose this feature would be great. I think a feature branch with automatic synchronisation would be a good idea.