prerelease creates releases based on the last stable release, not the last prerelease

[ryanobjc]

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?

[ryanobjc]

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]

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]

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:

• continuous deployment, but in a highly versioned manner - we can roll back dev too!
• releases have small version bumps, but big included changes. This fits a dev model where we want releases every 3-6 weeks, or whatever cadence we require.

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:

[package]
versioned_files = []

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:

• run knope to determine the version, update package.json etc
• do a build using my custom build logic, eg: docker build, etc
• run knope the last time to publish a release, potentially with artifacts.
• Not committing changes to package.json, etc, since the versions get bundled into the published artifacts.

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]

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:

• Fix tag-only releases (no versioned files)
• Add an incremental prerelease mode (for changelog only, the version will still be calculated from the previous stable)

[ryanobjc]

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]

@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]

Hopefully this is enough information for you to either figure it out, or reproduce the bug!

Unfortunately not, I wasn't able to reproduce locally. Any chance you could make a repo which reproduces the issue?