Repository navigation
Number versions after the Java version - #140
Merged
Merged
Conversation
Up to 2.98.0.6 the version was palantir-java-format's with a build number appended. The bug fixes made the output differ from upstream, so following its numbers lost its meaning. From here a version is <java>.<minor>.<build>: the Java version the formatter is built for, then a number that moves with every change to the output, then one that moves with builds that leave the output alone. The README gets a Versions section that says so, and the palantir section stops promising a 2.x line and changes waiting for 3.0.
The default branch is 21.X.X now, and a release line is named after the Java version it is built for, so the workflows that watched main alone also take '*.X.X': CI, CodeQL, the dependency graph, the SHA-pinning and zizmor checks. The PR updater follows 21.X.X, the base of every pull request, and dependabot loses its target-branch so that it opens its pull requests against the default branch, whichever line that is. Releases need nothing: release.yml runs on a tag, and JReleaser never compares the branch.
main is the old line and gets nothing new, so the workflows stop watching it: CI, CodeQL, the dependency graph, the SHA-pinning and zizmor checks run on '*.X.X' alone. dependabot names 21.X.X outright instead of following the default branch, and moves when the next line starts.
It is not a build counter but the number of fixes that leave the output alone: a crash, a regression, an internal bug, a dependency update. The line between it and the second number is the output, not the kind of change: a fix that changes the output raises the second, a fix that does not raises the third.
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.
Versions become
<java>.<minor>.<build>: the Java version the formatter is built for, then a number that moves with every change to the output, then one that moves with builds that leave the output alone. Up to 2.98.0.6 the version was palantir-java-format's with a build number appended; the bug fixes made the output differ from upstream, so following its numbers lost its meaning.'*.X.X', instead ofmain: CI, CodeQL, the dependency graph, the SHA-pinning and zizmor checks. The PR updater and dependabot name 21.X.X.Releases need nothing: release.yml runs on a tag and JReleaser never compares the branch (the 2.98.0.6 run went from a detached HEAD). The release and Plugin Portal regexes accept X.Y.Z, and the Eclipse OSGi mapping takes three numbers as it is.
act --listparses every workflow.CodeQL fails here for a reason that predates the PR: 21.X.X carries codeql-action init 4.38.2 and analyze 4.38.3, and CodeQL wants one version for every step; #137 brings init up and lands once the PR updater, which this PR points at 21.X.X, brings it up to date.
The matching changes are live on the site (openjavaformat/docs 6956c9b).