Repository navigation
prerelease creates releases based on the last stable release, not the last prerelease #1685
Description
I am using prereleases extensively (we want build artifacts for all our prereleases for cluster pushes). I found recently that prerelease-label=dev seems to create releases even if the last commit was something like 'ci' which should, in theory, not be eligible for creating a new release.
This is the verbose output of my knope release run:
Loading package
Cargo.toml has version 1.0.2-dev.9
Looking for Git tags matching package name.
Running step PrepareRelease(PrepareRelease { prerelease_label: Some(Label("dev")), allow_empty: false, ignore_conventional_commits: false })
Getting conventional commits since last release of package
Using commits since tag v1.0.1
commit fix: DGT-110 add sign and digital title
implies rule PATCH
commit fix: DGT-110 add create digital title to cli
implies rule PATCH
commit fix: DGT-110 cargo dist to use newer ubuntu
implies rule PATCH
commit fix: DGT-110 use newer ubuntu
implies rule PATCH
commit fix: DGT-110 dont have a linux arm64
implies rule PATCH
commit fix: DGT-110 dont publish a release in knope
implies rule PATCH
commit fix: DGT-110 dont forget to tag the release
implies rule PATCH
commit fix: DGT-110 push tags, also debug log
implies rule PATCH
commit fix: DGT-110 different push tags command
implies rule PATCH
commit fix: DGT-110 new dist config to not create releases
implies rule PATCH
Pre-release label dev selected. Determining next stable version...
Using PATCH rule to bump from 1.0.1 to 1.0.2
Found existing pre-release version dev.9
Running step Command { command: "git tag $version", variables: None, shell: None }
Running step Command { command: "git push origin $version", variables: None, shell: None }
So in this case my prior release was 1.0.2-dev.9 and I got a 1.0.2-dev.10, which was unexpected to me. I saw #213 which I am not sure how it fully interacts with my use case.
Is this a bug? Do I misunderstand how prereleases are supposed to work?
Activity
ryanobjc commentedon Dec 3, 2025
I think part of my problem is I don't want to commit a change to Cargo.toml on every single prerelease, then my git history is 50% these commits basically.
So knope is looking at Cargo.toml and ignoring tags seems?
dbanty commentedon Dec 3, 2025
The way Knope's prereleases work right now are as a full preview of an entire release, not as incremental changes. They're intended to be triggered manually, occasionally, when you need a preview build.
It sounds like your workflow is that every change triggers a new prerelease, so you want those to only trigger when there's a changelog-relevant change (fix, feature, etc.) and for that prerelease to only include the changes since the last prerelease, not since the last stable version.
I think it'd be easy enough to have a setting for what type of prereleases you'd like (incremental vs full). Would you still want the final changelog for the final version to include everything since the previous final version? Or just since the previous prerelease?
ryanobjc commentedon Dec 3, 2025
in the way we are using semantic-release workflows, we are issuing a pre-release on every change to 'dev' branch. The change will build a new container (server side apps) and then the dev cluster will auto-detect and roll that new version out. Then at the end of a sprint, or whatever, we merge dev -> main, and create a non-prerelease there.
The advantage of this workflow is:
In terms of the contents of the prerelease changelogs, it would probably make sense to just include whatever was included since the last prerelease. That way people who are following along with the prereleases can see how daily changes are adding/fixing things.
Then when it comes time to merge back to 'main' to do the "real" release, then the entirety of the changes since the last non-prerelease are bundled in. Thus the changelog/notes shows you what the last sprint or two of changes has accumulated to.
Another aspect of how this might work is if we have this commit stream, oldest to most recent:
feat: new feature - tag 1.1.0
fix: some fix - tag 1.1.1-dev.0
fix: some fix - tag 1.1.1-dev.0
feat: new feat - tag 1.2.0-dev.0
I think knope is doing this correctly right now. Basically the prerelease should be the 'next' releasable version, but with -dev.* (or whatever the label is).
I think I am 95% of the way there with knope, the big "problem" is needing to update Cargo.toml and not detecting the 'next' version from tags. I even set:
Part of the reason this is "working" is because I am using cargo-dist to build a binary, and it uses the tag to know what version.
In other repos where I don't have cargo-dist, I might use knope in a manner like so:
I have been using 'semantic-release' for this, but it's a bit inadequate outside npm world, and it's kind of a hefty dependency, so I am exploring alternatives!!
Thanks for the feedback!
dbanty commentedon Dec 4, 2025
Very strange that it is versioning Cargo.toml even if you explicitly tell it not to, I probably don't have any tests for tag-only projects 😅.
Okay so the action items to make this work for your flow are:
ryanobjc commentedon Dec 4, 2025
So with [package] versioned-files = [] I get really weird behavior.
The git history looks somewhat like this:
1d0cc0e origin/dev fix: ignore versioned files such as Cargo.toml
3b5bada ci: tweak repository access to trigger tag-workflows
9404a25 1.0.2-dev.10 ci: toml error, extra double quote
80895d1 ci: ensure we dont make an empty release
9017989 ci: change the release workflow to only tag, no commits
b9dfcb0 v1.0.2-dev.9 chore: prepare release 1.0.2-dev.9
(excuse the format, it looks better in color using magit!)
As you can see there is a tag 1.0.2-dev.10. The Cargo.toml says the version is 1.0.2-dev.9.
With versioned-files = [] knope consistently says the last tag was dev.9, regardless if I update Cargo.toml!
If I remove versioned-files, then knope figures out the last tag was dev.10 if I don't update Cargo.toml. In other words, knope does the right thing, it chooses the latest git tag (dev.10) over the erronous information in Cargo.toml.
If Cargo.toml has version set to 1.0.2-dev.10 well then everything is working normally.
There is something up with the tag detection logic seemingly. Hopefully this is enough information for you to either figure it out, or reproduce the bug!
dbanty commentedon Dec 4, 2025
@ryanobjc on incremental prereleases, do you only use conventional commits or also changesets?
For changesets I'm going to have to track which changes were already included in previous releases... probably using the same file as the NPM tool. So there'd still be an extra commit per release.
dbanty commentedon Dec 4, 2025
Unfortunately not, I wasn't able to reproduce locally. Any chance you could make a repo which reproduces the issue?
ryanobjc commentedon Jun 2, 2026
Okay I've finally gotten back around to this, and here is a repro in the form of a repository:
https://github.com/ryanobjc/knope-tutorial
So have a look at the version 1.4.0-dev.0-2. Each successive change has the accumulation of changes since the last major release. This is what I am talking about.
When we finally release 1.4.0 on main, it correctly includes all the accumulated changes, so that is GOOD.
Thinking about it a bit though, I am not really sure I am unhappy with this feature in the end. So maybe it's okay and this issue is moot?
ryanobjc commentedon Jun 12, 2026
I fixed this in PR #1930