You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current setup and possibilities for multibranch, maintenance, and prerelease, I messed up several times when merging the different branches together. As such, I merged a breaking change into my release branch that correctly created the new major version. However, the "main" branch - which creates prereleases for each commit - did not update that tag. Now, all further commits created newer versions of the old prerelease.
I thought about a solution for this kind of situation and had one idea: it would be nice to have a flag and/or config possibility that allows me to either have only prerelease branch configs, or trigger prereleases via cli flags.
As an example, I would setup my repository (on GitHub with GitHub Actions) to run a workflow on each commit that lands in "main". When this workflow runs, it adds --pre-release as CLI flag and therefore, depending on the new version, creates a new pre-release.
When I'm satisfied with all the changes currently present for the next release, I run a workflow_dispach (manual) or maybe also a scheduled workflow on GitHub that does not include this flag. This in turn should then result in the next non pre release version being published. As soon as a new commit lands in main, the new version will be a pre-release again.
New feature description
As far as I understand, only two changes are necessary:
Allow the branch configuration to have "only prerelease" branches present (when checking the config)
Add a cli flag --pre-release that forces the current branch (if configured) to create a pre-release instead of a normal release
With 2. being optional. When using 1., one could use the --branches flag to configure the pre-release on the fly.
In combination with the motivation description, this would result in:
commit on main branch: semantic-release --branches [{name: "main", prerelease: "whatever"}]
manual run on main branch: semantic-release or semantic-release --branches ["main"]
New feature implementation
I think only the check about the release branch config is different. Other elements are untouched since the logic remains the same with determining the new versions.
The text was updated successfully, but these errors were encountered:
New feature motivation
With the current setup and possibilities for multibranch, maintenance, and prerelease, I messed up several times when merging the different branches together. As such, I merged a breaking change into my release branch that correctly created the new major version. However, the "main" branch - which creates prereleases for each commit - did not update that tag. Now, all further commits created newer versions of the old prerelease.
I thought about a solution for this kind of situation and had one idea: it would be nice to have a flag and/or config possibility that allows me to either have only prerelease branch configs, or trigger prereleases via cli flags.
As an example, I would setup my repository (on GitHub with GitHub Actions) to run a workflow on each commit that lands in "main". When this workflow runs, it adds
--pre-release
as CLI flag and therefore, depending on the new version, creates a new pre-release.When I'm satisfied with all the changes currently present for the next release, I run a
workflow_dispach
(manual) or maybe also a scheduled workflow on GitHub that does not include this flag. This in turn should then result in the next non pre release version being published. As soon as a new commit lands in main, the new version will be a pre-release again.New feature description
As far as I understand, only two changes are necessary:
--pre-release
that forces the current branch (if configured) to create a pre-release instead of a normal releaseWith 2. being optional. When using 1., one could use the
--branches
flag to configure the pre-release on the fly.In combination with the motivation description, this would result in:
semantic-release --branches [{name: "main", prerelease: "whatever"}]
semantic-release
orsemantic-release --branches ["main"]
New feature implementation
I think only the check about the release branch config is different. Other elements are untouched since the logic remains the same with determining the new versions.
The text was updated successfully, but these errors were encountered: