0.19.1

NOTE: 0.19.1 is the same as 0.19.0. There was a publishing issue preventing 0.19.0 from getting out to Central.

This release makes commit message scope suppliers more flexible.

Use of scopeSupplier = calcScopeFromCommitMessages() allowed specifying the scope with a commit message like major: My Message or patch: My message. However, there was a special case when the project hadn't reached 1.0.0 yet.

Before a project reaches 1.0.0, major: prefixes were downgraded to minor. The intent was to encourage breaking changes to still be committed as major: for consistency, but respecting that reaching 1.0.0 is a more significant decision than just the first breaking change introduced into your code.

The downside was that the only alternative to get to 1.0.0 was to use -Preckon.scope=major to supersede what the commit message supplier decided. This can be incompatible with many workflows that don't allow user interaction when reckon runs.

With this release:

• scopeSupplier = calcScopeFromCommitMessages() now additionally supports a major!: prefix which ignores whether the project is pre-1.0.0 and forces use of the major scope
• Introduces scopeSupplier = calcScopeFromCommitMessageParser(BiFunction) which allows custom logic to consider both the commit message and whether the project is pre-1.0.0 when it makes it's scope decision
• scopeSupplier = calcScopeFromCommitMessages(Function) continues to use the same pre-1.0.0 behavior when a major scope is returned for backwards compatibility

Breaking Changes

None

Enhancements

• #205 Allow commit message scope suppliers to bump version to v1.0.0

Fixes

• Dependency updates

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.6.4, 8.0.2, 8.11.1
17	7.3.3, 7.6.4, 8.0.2, 8.11.1
21	8.4, 8.11.1

0.19.0

This release makes commit message scope suppliers more flexible.

Use of scopeSupplier = calcScopeFromCommitMessages() allowed specifying the scope with a commit message like major: My Message or patch: My message. However, there was a special case when the project hadn't reached 1.0.0 yet.

Before a project reaches 1.0.0, major: prefixes were downgraded to minor. The intent was to encourage breaking changes to still be committed as major: for consistency, but respecting that reaching 1.0.0 is a more significant decision than just the first breaking change introduced into your code.

The downside was that the only alternative to get to 1.0.0 was to use -Preckon.scope=major to supersede what the commit message supplier decided. This can be incompatible with many workflows that don't allow user interaction when reckon runs.

With this release:

• scopeSupplier = calcScopeFromCommitMessages() now additionally supports a major!: prefix which ignores whether the project is pre-1.0.0 and forces use of the major scope
• Introduces scopeSupplier = calcScopeFromCommitMessageParser(BiFunction) which allows custom logic to consider both the commit message and whether the project is pre-1.0.0 when it makes it's scope decision
• scopeSupplier = calcScopeFromCommitMessages(Function) continues to use the same pre-1.0.0 behavior when a major scope is returned for backwards compatibility

Breaking Changes

None

Enhancements

• #205 Allow commit message scope suppliers to bump version to v1.0.0

Fixes

• Dependency updates

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.6.4, 8.0.2, 8.11.1
17	7.3.3, 7.6.4, 8.0.2, 8.11.1
21	8.4, 8.11.1

0.18.3

Dependency updates. The zafarkhaja/semver library had a bunch of breaking changes, but it doesn't appear that any of those will affect the outward behavior. Please open an issue if you find otherwise.

Breaking Changes

None

Enhancements

None

Fixes

• Dependency updates

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.6.4, 8.0.2, 8.6
17	7.3.3, 7.6.4, 8.0.2, 8.6
21	8.4, 8.6

0.18.2

Minor improvement for people interacting with the tasks during another settings plugin. Also now tested against Gradle 8.5.

Breaking Changes

None

Enhancements

None

Fixes

• #200 Register tag/push tasks earlier to make settings plugins easier

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.6.1, 8.0.2, 8.5, 8.6-rc-1
17	7.3.3, 7.6.1, 8.0.2, 8.5, 8.6-rc-1
21	8.4, 8.5, 8.6-rc-1

0.18.1

Small patch release to update dependencies and resolve a deprecation.

Breaking Changes

None

Enhancements

None

Fixes

• #199 Update Gradle and dependencies
• #198 Remove use of deprecated forUseAtConfigurationTime function from Gradle

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.6.1, 8.0.2, 8.4
17	7.3.3, 7.6.1, 8.0.2, 8.4
21	8.4

0.18.0

This release decouples reckon from grgit, using direct JGit for version inference and CLI Git for tag creation and pushes. The motivation is selfishly just to simplify maintenance of reckon.

For most cases, this should be a transparent change, but it does have a few potentially user-facing effects:

• You have to have git installed (which you almost certainly do)
• If you use reckonTagPush, you must have your credentials set up already in some way that won't require a prompt (basic auth creds, SSH agent, whatever). The old org.ajoberstar.grgit.* properties or GRGIT_* environment variables are no longer used.

Generally, we will be using the current user's identity (user.email and user.name) to create the tag. In cases where that information is not present (for example, in GitHub Actions), we'll use the author identity from the most recent commit.

This release contains a couple other small changes as well, see below.

Breaking Changes

• #196 grgit is completely removed from reckon (affecting authentication and tagging)
• #195 defaultInferredScope no longer defaults to minor and must be set explicitly

Enhancements

• #175 The Scope enum is now accepted for defaultInferredScope and parallelBranchScope

Fixes

• #91 You can run your build with --info to see status details from JGit if reckon fails due to an unclean repo

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.6.1, 8.0.2, 8.1.1
17	7.3.3, 7.6.1, 8.0.2, 8.1.1

0.17.0

This release implements a new org.ajoberstar.reckon.settings plugin that can be used as an alternative to org.ajoberstar.reckon. This is applied in a settings.gradle instead of a build.gradle but is otherwise configured the same. By applying to Settings, it will run and be configured before any projects are evaluated, which should avoid the timing issues uncovered in #147. The settings plugin does not have the same "soft-fail" workaround that the project plugin has, as it should not be needed.

Additionally we have improvements to version inference logic. Our prior parallel version logic allowed reckon to increment by the requested scope a second time in order to avoid a parallel version. However, if that version is also in the parallel branch, it would fail saying the version was already claimed.

In the new logic, you are able to set a parallelBranchScope to indicate how you use your parallel branches. For example, people use branches like maintenance/1.2.x should set it to MINOR. Users of branches like maintenance/2.x should set it to MAJOR.

When reckon identifies a conflict with a parallel branch, it will increment by the greater of the user-provided scope and parallelBranchScope.

 O abc123
 O abc124 (v1.2.0)
 | \
 |  O abc125 (v1.2.1)
 O abc126

In the old logic, commit abc126 would infer as 1.2.2-alpha.0.1+abc126 where in the new logic (with parallelBranchScope=MINOR) it would infer as 1.3.0-alpha.0.1+abc126.

Breaking Changes

• #183 Insignificant versions will never use the parallel version avoidance logic. This is mainly targeted to benefit feature branches that aren't up to date with your main branch, however it can also affect the main branch if it hasn't been tagged since a parallel branch was created and tagged.

Enhancements

• New org.ajoberstar.reckon.settings plugin that can be applied in settings.gradle as an alternative to the normal plugin. This ensures reckon gets configured before project plugins.

Fixes

• #180 Parallel branch with two released versions will cause failure due to claimed version
• #194 Version inference exceptions are no longer buried by the "soft-fail" logic in the project plugin

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.6.1, 8.0.2, 8.1.1
17	7.3.3, 7.6.1, 8.0.2, 8.1.1

0.17.0-beta.4

This release implements a new org.ajoberstar.reckon.settings plugin that can be used as an alternative to org.ajoberstar.reckon. This is applied in a settings.gradle instead of a build.gradle but is otherwise configured the same. By applying to Settings, it will run and be configured before any projects are evaluated, which should avoid the timing issues uncovered in #147.

Additionally we have improvements to version inference logic. Our prior parallel version logic allowed reckon to increment by the requested scope a second time in order to avoid a parallel version. However, if that version is also in the parallel branch, it would fail saying the version was already claimed.

In the new logic, you are able to set a parallelBranchScope to indicate how you use your parallel branches. For example, people use branches like maintenance/1.2.x should set it to MINOR. Users of branches like maintenance/2.x should set it to MAJOR.

When reckon identifies a conflict with a parallel branch, it will increment by the greater of the user-provided scope and parallelBranchScope.

 O abc123
 O abc124 (v1.2.0)
 | \
 |  O abc125 (v1.2.1)
 O abc126

In the old logic, commit abc126 would infer as 1.2.2-alpha.0.1+abc126 where in the new logic (with parallelBranchScope=MINOR) it would infer as 1.3.0-alpha.0.1+abc126.

Breaking Changes

• #183 Insignificant versions will never use the parallel version avoidance logic. This is mainly targeted to benefit feature branches that aren't up to date with your main branch, however it can also affect the main branch if it hasn't been tagged since a parallel branch was created and tagged.

Enhancements

• New org.ajoberstar.reckon.settings plugin that can be applied in settings.gradle as an alternative to the normal plugin. This ensures reckon gets configured before project plugins.

Fixes

• #180 Parallel branch with two released versions will cause failure due to claimed version

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.5.1
17	7.3.3, 7.5.1

0.17.0-beta.3

This release implements a new org.ajoberstar.reckon.settings plugin that can be used as an alternative to org.ajoberstar.reckon. This is applied in a settings.gradle instead of a build.gradle but is otherwise configured the same. By applying to Settings, it will run and be configured before any projects are evaluated, which should avoid the timing issues uncovered in #147.

Additionally we have improvements to version inference logic. Our prior parallel version logic allowed reckon to increment by the requested scope a second time in order to avoid a parallel version. However, if that version is also in the parallel branch, it would fail saying the version was already claimed.

In the new logic, you are able to set a parallelBranchScope to indicate how you use your parallel branches. For example, people use branches like maintenance/1.2.x should set it to MINOR. Users of branches like maintenance/2.x should set it to MAJOR.

When reckon identifies a conflict with a parallel branch, it will increment by the greater of the user-provided scope and parallelBranchScope.

 O abc123
 O abc124 (v1.2.0)
 | \
 |  O abc125 (v1.2.1)
 O abc126

In the old logic, commit abc126 would infer as 1.2.2-alpha.0.1+abc126 where in the new logic (with parallelBranchScope=MINOR) it would infer as 1.3.0-alpha.0.1+abc126.

Breaking Changes

None

Enhancements

• New org.ajoberstar.reckon.settings plugin that can be applied in settings.gradle as an alternative to the normal plugin. This ensures reckon gets configured before project plugins.

Fixes

• #180 Parallel branch with two released versions will cause failure due to claimed version

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.5.1
17	7.3.3, 7.5.1

0.17.0-beta.2

This release implements a new org.ajoberstar.reckon.settings plugin that can be used as an alternative to org.ajoberstar.reckon. This is applied in a settings.gradle instead of a build.gradle but is otherwise configured the same. By applying to Settings, it will run and be configured before any projects are evaluated, which should avoid the timing issues uncovered in #147.

Additionally we have improvements to version inference logic. Our prior parallel version logic allowed reckon to increment by the requested scope a second time in order to avoid a parallel version. However, if that version is also in the parallel branch, it would fail saying the version was already claimed.

In the new logic, if we bump the target normal in order to avoid a parallel version and that version is still in the parallel versions
list, we increment by a higher scope (i.e. by MAJOR if they requested MINOR or by MINOR if they requested PATCH).

This may resolve many of the bugs we had with parallel version handling.

The two unintuitive parts are that it may still not increment as far as someone wants in some cases. And in others someone could be surprised that we incremented by a higher scope than they asked for.

To deal with the latter, we may want to consider making a distinction between "soft" and "hard" scopes (i.e. did they explicitly ask for the scope or did it get inferred). This was clearer in the past, when "inferred" really only meant no input from the scope calc. However, with the new commit message scope calc, that's really more of a "soft" scope request than an explicit one. It's trickier because to the Reckoner there's no difference between commit message scope calcs and explicit user-requested scope calcs.

Breaking Changes

• #181 results in cases where reckon may increment with a higher scope than the user provided in order to avoid parallel versions. In past versions, this would have failed instead saying the version was already claimed

Enhancements

• New org.ajoberstar.reckon.settings plugin that can be applied in settings.gradle as an alternative to the normal plugin. This ensures reckon gets configured before project plugins.

Fixes

• #180 Parallel branch with two released versions will cause failure due to claimed version

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.5.1
17	7.3.3, 7.5.1