Studio 3.0.0: the candidate becomes the release, and the first Studio 2.0.0 will be offered - #209
Merged
Conversation
… 2.0.0 will be offered The application does not change here. `<Version>` goes from `3.0.0-rc.2` to `3.0.0` and the changelog gets the section that says so - what the candidate existed for has already happened: it was walked on Windows against a calibration database, six of its eleven findings were fixed, four were written up, and both tracks on all three platforms were built and signed. What the version alone changes is who sees it. The release workflow derives `prerelease` from the tag suffix, so `studio-v3.0.0` is the first Studio tag that becomes the repository's Latest - and the update check inside 2.0.0 only offers Latest. That is why the entry is written for a 2.0.0 user rather than for somebody following the project, and why it names the one thing that can stop one: engine 14.0.0 refuses a database encrypted before 13.1.0, and Studio is the tool that converts it. The workflow's own gate is the reason the csproj bump is not optional - it refuses a tag whose version disagrees with the csproj, because otherwise the installers are named for the tag while the application reports the csproj version in its About panel and to the update check. Studio 903 green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The application does not change here.
<Version>goes from3.0.0-rc.2to3.0.0, and the changeloggets the section that says so.
What the candidate existed for has already happened: rc.2 was walked on Windows against a calibration
database, six of its eleven findings were fixed and four written up, and both tracks on all three
platforms were built and signed (Authenticode, notarize + staple, GPG-signed
SHA256SUMS).What the version alone changes is who sees it. The release workflow derives
prereleasefrom thetag suffix, so
studio-v3.0.0is the first Studio tag that becomes the repository's Latest — and theupdate check inside 2.0.0 only offers Latest. The changelog entry is therefore written for a 2.0.0
user rather than for somebody following the project, and it names the one thing that can stop one:
engine 14.0.0 refuses a database encrypted before 13.1.0, and Studio is the tool that converts it.
The csproj bump is not optional: the workflow refuses a tag whose version disagrees with the csproj,
because otherwise the installers are named for the tag while the application reports the csproj
version in its About panel and to the update check.
Studio 903 green.
🤖 Generated with Claude Code