semantic-release: EINVALIDNEXTVERSION error when releasing a patch from maintenance branch
Current behavior
- release a new version
1.0.0
frommaster
branch - continue adding new features commits on
master
(likefeat(module): ...
) without releasing a new version from master branch - hotfix the previous version
1.0.0
to add a fix for1.0.0
users. Here I cannot do the fix from master since I added new features onmaster
and I don’t want them to be included in the fix. So I create a hotfix branchgit checkout -b 1.0.x v1.0.0
- push the fix on the
1.0.x
branch and try to release a patch - semantic release raising the following error:
[semantic-release] › ✖ EINVALIDNEXTVERSION The release `1.0.1` on branch `1.0.x` cannot be published as it is out of range.
Based on the releases published on other branches, only versions within the range >=1.0.0 <1.0.0 can be published from branch 1.0.x.
- if I create a new version on master
1.1.0
and re-do the process described above, the hotfix release1.0.1
is successfully be created from the1.0.x
hotfix branch
Expected behavior
I can continue adding new features on master
since the last 1.0.0
release without being ready yet to release a new version. In the meantime, I might have the need to add a fix to the previously released version 1.0.0
but not from master
to avoid including the newly added features.
So I would like to be able to patch
release 1.0.1
from the hotfix branch while the version on master is not incremented yet (latest release on master 1.0.0
).
Environment
- semantic-release version:
17.0.4
- CI environment:
Gitlab
- Plugins used:
[
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/changelog",
"@semantic-release/npm",
"@semantic-release/git"
]
- semantic-release configuration: default settings
- CI logs:
[semantic-release] › ✖ EINVALIDNEXTVERSION The release
1.0.1
on branch1.0.x
cannot be published as it is out of range. Based on the releases published on other branches, only versions within the range >=1.0.0 <1.0.0 can be published from branch 1.0.x.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 23
- Comments: 24 (1 by maintainers)
I’ve encountered the same problem with different versions of semantic-release.
But I’ve I discovered that it only happens when you try to publish a new maintenance version from a maintenance branch that has been created from the last tag/HEAD of the release branch (master)
Reproducible case
In my config below, I have 3 branches:
As you can see in the previous git graph, I created the 1.0.x branch from the tag v1.0.0 in order to create maintenance releases. But when semantic releases is executed in this branch, it reports the EINVALIDNEXTVERSION error.
Important is to notice that this does not happen in the next case, which is basically the same scenario but when the maintenance doesn’t start anymore from the last tag/HEAD of release branch (master).
In this case, as you can see, a new 1.1.0 version has been published in master. So, when the maintenance version is released in 1.0.x there’s no problem anymore -> 1.0.1
Before releasing in 1.0.x
After releasing in 1.0.x -> 1.0.1
I believe that both scenarios are valid, since both are basically the same. But in case I’m wrong, could you point me out what would be incorrect?
Configuration
I’ll leave the details of my configuration below:
Environment
I did other tests replacing
"@semantic-release/git"
and"@semantic-release/npm"
with"@semantic-release/exec"
- semantic-release configuration (open for more defails)
- CI logs (open for more details):
✖ EINVALIDNEXTVERSION The release
1.0.1
on branch1.0.x
cannot be published as it is out of rangeThis was a great thread to read, and ultimately a show stopper for me. @Kehrlann comment above convinced me that this may never be a supported workflow for semantic-release. I’m not sure that @grv87 “semantic-release principle to release on each push” means that the workflow that this issue wants is unachievable. I am using gitversion now instead (https://gitversion.net/) My two cents are below - but i want to be 100% clear, like @Kehrlann i’m not suggesting this product changes as it’s doing lots already !
I believe there is an impedance between branching models and release workflows. This comes from an unclear definition of how version numbers will be reserved relating to release channels - and from the constraints around artifact repositories and git.
I’m working in an enterprise delivering internal and external software. These can be libraries and applications. It’s delivered through a sequence of stages or environments. Releases are to internal and external channels. Libraries builds are fully automated - but I’m not sure i should call that continuous deployment (one of many points that aren’t formal enough) - but otherwise we aim for continuous delivery - not continuous deployment.
We use githubflow, and oneflow as branching models https://www.abtasty.com/blog/git-branching-strategies/, https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow - and are automating them, hence the investigation of semantic-release and gitversion. I aimed to use one of these two tools to automate the version numbering
Gitversions doco and tool revolves around the known branching models of githubflow and gitflow more. It has a couple of different strategies for calculating version numbers (branch name based) and config based, and commit based numbering is not quite as prominent. As a result these possibly allow for more strategies to
So, oneflow and github flow model, that support stabilising before external releasing OR mainline fixes to prerelease channels with retrospective hotfixes aren’t easily compatible with choosing at commit time a major.minor.patch number. Since semantic release is really aiming to make version numbering strongly convention (unromantic), I’m not sure this can be easily reconciled !
I hope by introducing some of these terms that it might be possible to clarify what the limits of semantic release are and improve it’s doco. Since you might have arrived here like i did hoping to automate versioning on top of a branching model, that should also include how those limts relates to what branching model you can have.
The issue is still present on
19.0.x
I’ve made other tests with the configuration and the workflow that are described in the documentation (maintenance release and pre-releases) and I can replicate the problem. I’ve combined both recipes to have my use case, pretty similar to what @stratosgear said.
This is my current git graph
Branches
What I would like to accomplish would be…
After releasing v3.0.0, I started adding new features to the beta branch for the future v3.1.0. But while I was developing these new features, a new bug was reported in the v3.0.0, so I created 3.0.x branch to fix it. In that branch, I added a commit
"fix: maintenance fix"
and pushed to the branch 3.0.x.What I expected is that the version 3.0.1 would have been released in that branch. Instead I got the
"EINVALIDNEXTVERION"
errorI keep thinking that this should be a valid workflow. But if it’s not I’d appreciate some guidance 😉
It may or may not be a
develop
branch. That takes in a lot of assumptions. It is trunk. And the intention is to not have long-lived branches. At the same time, the project is not ready for continuous delivery.Also does the “semantic-release principle to release on each push” mean that every release contains only single feature or fix (in its changelog)?
So my question is: can this scenario work? As an opt-in feature? You would remove the check and thrown error. My only concern is determining the next release on trunk after such hotfix.
@travi, could you please give some guidance on the situation (this issue and the open PR #1971)? Thank you!
I forgot to mention it here, but I created a PR with the possible fix for the workflow that I mentioned before. Just letting you know in case Github hasn’t sent a notification 😉
@mrmartan I think in this case, it does not matter if it’s a
maintenance branch
orhotfix branch
, essencially is the same concept and the wrong behavior is present in both cases.For example, try following the next steps. If you take exactly that state of your example and:
feat: add new feature
That last step was not possible before having the 6.6.0 because of the bug.
From what I’ve seen, semantic-release isn’t able to release from maintenance/hotfix branches when:
I don’t think this is a bug. I think this is rather a
hotfix release
feature request,I am currently trying to implement just that on my project and I am running into this error.
Now I have new additions on my trunk (
next
branch) that I do not want to release just yet. I still need to publish a hotfix release 6.5.1 from branch6.5.x
(I could be cherry-picking the fix commit from trunk but that changes nothing).I think this a different workflow to what
maintenance branches
ofsemantic-release
offer.EDIT: job log
it’s okay to ping me if you think I can help, thank you! I don’t have time to look more into it right now but I’ll get back to it eventually. Thanks for helping out!