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

0.17.0-beta.1

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

• None

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.16.1

This provides a fix for NullPointerExceptions that have become more common with changes in Gradle 7.4 that stem from evaluation order issues and other plugins that call project.getVersion().toString() at configuration time. This allows builds to work, though there is some small risk that some config in the project will have the incorrect version unspecified instead of the desired version reckon would calculate.

In the cases where you see the following warning:

Project version evaluated before reckon was configured. Run with --info to see cause.

You can rerun the build with --info to see the exception that would have been thrown in prior versions. This can help you track down which plugin is too eagerly evaluating the version, in case you want to try to fix that.

Breaking Changes

None

Enhancements

• None

Fixes

• #147 and #174 Soft fail if reckon extension isn't configured instead of throwing an exception

Deprecations

None

Compatibility

Tested against the following versions.

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