chore: latest-7

[andredestro]

No description provided.

[jcesarmobile]

I'm not familiar with the release.config.cjs file, but shouldn't that change be made on main branch instead of in 7.x?

And I think release_plugin.yml file should also be updated to allow 7.x branch, unless we don't want automatic releases, I see main was first added but then removed.

[OS-pedrogustavobilro]

I'm not familiar with the release.config.cjs file, but shouldn't that change be made on main branch instead of in 7.x?

I am 80% sure this only needs to be on the branch from which the release will run.

So soon main will be for latest which will be Cap 8.

We won't be using next until Cap 9 (or ever again if we decide to drop it)

And 7.x will run for latest-7.

Then the GitHub action runs from the branch we select, so when running for 7.x it will clone the repo at that branch, and will run semantic-release with the config from that branch.

I say I'm 80% sure, because we properly haven't done this (releases with maintenance branches) for semantic-release yet, but I remember testing in the past with --dry-run locally and that's what happened. It's a matter of running the pipeline after the PR is merged and see what happens (it won't trigger a release, but it should not say that the branch is missing in the logs).

And I think release_plugin.yml file should also be updated to allow 7.x branch, unless we don't want automatic releases, I see main was first added but then removed.

This is a matter for debate I suppose, sometimes with PRs merged to main it would generate a release right away when in fact I wanted to bundle two PRs in same release. For maintenance branches, I guess it's not really a problem because I don't think we'll be bundling loads of patches.

That being said, in my opinion I'm fine as is, and would prefer removing the automatic triggers altogether, so that we're conscious on what we release - at least that's what we have for older capacitor repos.