set tlBaseVersion := "2.13"

[satorg]

Seems required to prevent CI from failing with

java.lang.RuntimeException: Your tlBaseVersion 2.12 is behind the latest tag 2.13.0

(see #4703 (comment))

[satorg]

@armanbilge does it mean that we have to bump up tlBaseVersion for every minor release at least?

Because to me this doc is not very clear about that:
https://typelevel.org/sbt-typelevel/faq.html#how-do-i-introduce-breaking-changes-intended-for-my-next-version

How do I introduce breaking changes intended for my next version?

Bump your tlBaseVersion to the next breaking-version according to early-semver, e.g. 0.7 to 0.8 or 4.2 to 5.0.

But we didn't introduce breaking changes in v2.13.0 comparing to v2.12.0, or did we?

[bpholt]

does it mean that we have to bump up tlBaseVersion for every minor release at least?

Yes, if the minor version changes, tlBaseVersion will also need to be changed accordingly.

Because to me this doc is not very clear about that: https://typelevel.org/sbt-typelevel/faq.html#how-do-i-introduce-breaking-changes-intended-for-my-next-version

How do I introduce breaking changes intended for my next version?

Bump your tlBaseVersion to the next breaking-version according to early-semver, e.g. 0.7 to 0.8 or 4.2 to 5.0.

But we didn't introduce breaking changes in v2.13.0 comparing to v2.12.0, or did we?

That FAQ entry is for when you do need to make a breaking change. The next one is a little more informative for your question. The tl;dr is that tlBaseVersion needs to be updated whenever the first two components (x.y) of the version change.

[armanbilge]

But we didn't introduce breaking changes in v2.13.0 comparing to v2.12.0, or did we?

Actually, we did :)

1. we didn't introduce any binary-breaking changes, but we did introduce several source-breaking changes. i.e. we don't guarantee that a codebase that compiles with Cats v2.12.0 will compile with v2.13.0, without making changes to source-code (source-compatibility). Source-breaking changes also generally break forwards binary-compatibility (but not backwards binary-compatibility, which is most important).

2. We also broke forward compatibility when we updated Scala.js, Scala Native, and Scala 2.13 to new minor versions (which also broke forward compatibility)

Both of these are reasons to bump the minor version, which we do via the base version. In fact, the correct time to bump tlBaseVersion is in the PR that makes those changes. This would be easier to be on top of if we had tooling support:

• Support checking forward-compatibility with MiMa sbt-typelevel#262
• A way to detect breaking dependency updates sbt-typelevel#185

[armanbilge]

Historically, I've bumped to the next base version immediately after a release (in this case, we would bump straight to 2.14). But I've only done that, because in general we are not very disciplined at bumping when we are supposed to 😅

• Bump base version to 2.10 #4341

[satorg]

@armanbilge , hmm... I'm not sure I got this:

we don't guarantee that a codebase that compiles with Cats v2.12.0 will compile with v2.13.0

I believe if some codebase had been compiling with v2.12.0 then upgraded to v2.13.0, then no source changes should be necessary to keep it compiling with v2.13.0 whatsoever (unless we introduces a bug, but that's a different story). What am I missing here?

Historically, I've bumped to the next base version immediately after a release (in this case, we would bump straight to 2.14). But I've only done that, because in general we are not very disciplined at bumping when we are supposed to.

I can change it to "2.14" in this PR, if it makes sense.

My only concern is then – why cannot we set it to "2.999" then once and until we grow up to the next major release?

[satorg]

I think we'd better off to merge this one as is now to unblock updates. We can catch up in following PRs.