Repository navigation
feat(prepare): Handle prereleases in auto-versioning and add pre version - #957
Merged
Merged
Conversation
…leases Auto-versioning analyzed commits since the latest tag, even when that tag was a prerelease. Promoting a prerelease with no new commits failed with "no commits found since the last release", and the changelog of the stable release listed only the changes since the last prerelease. Auto-versioning and the changelog of a stable release now start from the latest stable tag. The bump still applies to the latest tag, so 14.0.0-alpha.5 becomes 14.0.0. Prereleases keep their changelog since the previous tag. Co-Authored-By: BYK <126780+BYK@users.noreply.github.com>
Contributor
|
BYK
requested changes
Nov 3, 2026
BYK
left a comment
BYK
left a comment
Member
There was a problem hiding this comment.
Okay, let's refine the design a bit:
- We should have a
premagic version to cut the next pre-release - If the latest release was a pre release and the next version is a major,
autoshould cut a new pre release to be safe - When doing a pre-release it should list the changes since the last relevant pre-release if there is one. Like 14.0.0-alpha.5 should list changes from 14.0.0-alpha.4 but if we are cutting 14.0.0-alpha.0 we shouldn't get diff from 13.0.0-alpha.3 for instance but whatever the latest 13 stable release was. Or if it was 14.1.0-alpha.0, then it should be whatever stable was before 14.1.0 like 14.0.12.
- Any "stable" release should just get the diff from the previous stable release, ignoring any pre-releases in between.
Makes sense?
…major - `pre` cuts the next prerelease: it continues the current series when the bump stays in it (14.0.0-alpha.5 -> 14.0.0-alpha.6) and starts a new one otherwise (13.9.0 with a major bump -> 14.0.0-alpha.0). - After a prerelease, `auto` cuts another prerelease instead of a major release. Pass the version or `major` to release it. - A prerelease's changelog lists the changes since the previous prerelease of the same major.minor.patch, or since the latest stable tag when it starts a new series. Stable releases still list the changes since the latest stable tag.
sentry-junior
Bot
changed the title
pre version
BYK
requested changes
Nov 3, 2026
…ease calculatePrerelease() now takes the version auto would release instead of a bump type, so pre reads as "auto, then make it a prerelease": 1.9.0 -> 1.9.1-alpha.0 for a patch, 1.10.0-alpha.0 for a minor. Behavior is unchanged. Renames the e2e tests to name the versions they release.
BYK
requested changes
Nov 3, 2026
…on a real repo - `pre` needs minVersion >= 3.9.0, like other versioning features that are gated on the Craft version that introduced them. - Replace the mocked getLatestStableTag tests, which asserted git arguments, with tests that read tags from a real repository. - Use 2.1.0-alpha.3 -> 2.1.0 as the promotion example in the docs, since a major release after a prerelease stays a prerelease with auto.
BYK
approved these changes
Nov 3, 2026
BYK
added a commit
to getsentry/junior
that referenced
this pull request
Nov 3, 2026
…eople involved (#2623) A requester reviewed their own Junior pull request (getsentry/craft#957). The watch reply mentioned them and then named their GitHub login as a second person: "@burak Yigit Kaya BYK requested changes on …". The doer resolved to the right Slack user, so identity linking works. The gap is in the doer line of the task input. It says "write to them as you, and do not also call them <handle>" only when the doer is also in People involved. The webhook adds People involved only to approval and merge events. For `changes_requested` and `commented` reviews, the agent got "That is the same person" with no rule against the double naming. The junior-prod watch intent then asks it to mention the requester and to name the reviewer, so it did both. The fix adds the rule for a doer outside People involved: "If you mention them, write to them as "you", and do not also call them "<handle>"." The People involved wording does not change. <!-- junior-request-attribution:start --> via @BYK. <!-- junior-request-attribution:end --> <!-- junior-session-footer:start --> <!-- junior-conversation-id:local%3Aweb%3A7e24d58bb1265f0d1dbcdff7 --> -- [View Session in Sentry](https://sentry.sentry.io/explore/conversations/local%3Aweb%3A7e24d58bb1265f0d1dbcdff7/?project=4510944073809921) <!-- junior-session-footer:end --> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: BYK <126780+BYK@users.noreply.github.com>
8 tasks done
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
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.
Auto-versioning analyzed commits since the latest tag, even when that tag was a prerelease. After
getsentry/symbolicreleased14.0.0-alpha.5,craft preparewithversioning.policy: autofailed because no commits came after the alpha (run):The GitHub release, npm (
next), crates.io, and PyPI already treat14.0.0-alpha.5as a prerelease, so publishing doesn't need a fix. Onlypreparepicked the wrong base.Behavior
Version (
auto,pre, bump types)autoandprepick the bump type from the commits since the latest stable tag. The bump applies to the latest tag.preversion: calculates the versionautowould release and cuts a prerelease of it. After1.9.0that's1.9.1-alpha.0for a patch,1.10.0-alpha.0for a minor, or2.0.0-alpha.0for a major. If the latest tag is already a prerelease of that version,precuts the next one instead:14.0.0-alpha.5→14.0.0-alpha.6.autowould cut a major release, it cuts the next prerelease instead and logs how to get the stable release (craft prepare 14.0.0ormajor). Non-major promotions still go stable:1.1.0-alpha.0→1.1.0.majorafter14.0.0-alpha.5gives14.0.0.Changelog base (also the
previous_tagoutput used for the publish issue's "View changes" link)14.0.0lists everything since13.9.0, including what the alphas shipped.major.minor.patch(14.0.0-alpha.5follows14.0.0-alpha.4). If there isn't one, the latest stable tag (14.1.0-alpha.0follows14.0.12, not14.0.0-alpha.3).preReleaseCommandstill gets the latest tag as the old version, because that version is what the project files contain.Implementation
git.ts:findLatestTag()runsgit describeagain with--excludefor each tag it rejects, scoped to the tag prefix.getLatestStableTag()andgetChangelogBaseTag()are built on it. When tags exist but none can describe HEAD (fatal: No tags can describe), the lookups return'', just like when there are no tags.autoVersion.ts:calculatePrerelease(version, currentVersion). New series use thealphaidentifier.prepare.ts: acceptspre, applies the rules above, and usesgetChangelogBaseTag()for the changelog.versioning.md) and theversioninput description inaction.yml.craft changelog(the PR preview) still uses the latest tag.Verification
calculatePrerelease,getLatestStableTag,getChangelogBaseTag, and acceptingpre. Two e2e dry-run tests: promoting1.1.0-alpha.1to1.1.0, andautocutting2.0.0-alpha.1after2.0.0-alpha.0with a changelog of only the new commit.pre→1.1.0-alpha.0(since1.0.0),pre→1.1.0-alpha.1(sincealpha.0),auto→1.1.0(since1.0.0), explicit2.0.0-alpha.0(since1.0.0),preafter a breaking change →2.0.0-alpha.0,auto→2.0.0-alpha.1,major→2.0.0(since1.0.0).tsc,eslint, andprettierpass. My sandbox's git wrapper rejects the test author overrides, so I couldn't run the e2e file there. CI passed on the first commit.--
View Session in Sentry