Should we allow 'mixed versioning'?

[raboof]

Currently, Pekko does not allow 'mixed versioning' - please read https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html#mixed-versioning-is-not-allowed to get the background.

This is causing confusion: people see the IllegalStateException and assume there is something wrong with Pekko, not with their project.

We could consider dropping the requirement to have aligned versions. This means we can no longer make changes to, say, pekko-stream that also require changes to pekko-actor (even when remaining binary compatible in the user-facing API).

Personally, I think requiring aligned versions for artifacts that are released together (e.g. between pekko-actor and pekko-stream, but not between pekko-actor and pekko-connector-mqtt) is reasonable, and allowing mixed versioning would restrict changes too much.

We should probably make the behavior less confusing, though. Perhaps instead of logging an IllegalStateException, we should explain the problem in an ERROR-level log message and shut down?

[pjfanning]

We have a config to disable the check. pekko.fail-mixed-versions=off
I think Akka and existing Pekko users are used to check so I would prefer to keep some form of check - especially since it can be turned off.
We have BOMs like pekko-bom but these might not be supported by sbt (but help with Maven and Gradle).
I am not against changing away from the way the issue is reported and think that Arnout's suggestion repeated below is worth considering.

We should probably make the behavior less confusing, though. Perhaps instead of logging an IllegalStateException, we should explain the problem in an ERROR-level log message and shut down

We could also consider only comparing the major and minor parts the x.y.z version number but allow flexibility with the patch part of the version number ('z' in x.y.z).

[mdedetrich]

We could also consider only comparing the major and minor parts the x.y.z version number but allow flexibility with the patch part of the version number ('z' in x.y.z).

By definition of semver patch bump's shouldn't add new functionality, only fix anything thats currently there so on surface level this seems okay. @raboof wdyt?

[raboof]

We have a config to disable the check. pekko.fail-mixed-versions=off
I think Akka and existing Pekko users are used to check so I would prefer to keep some form of check - especially since it can be turned off.

We should probably make the description of that option clearer though: if you disable this check, can you expect your application to work? I think this should be a strictly "at your own risk" choice, and we should be free to make changes that break in that case.

[raboof]

By definition of semver patch bump's shouldn't add new functionality, only fix anything thats currently there so on surface level this seems okay

I don't know how strictly we plan to follow semver. For Akka, we've been using it quite loosely, e.g. allowing new features in a patch release, and this has served us well. If we continue down that path, loosening the version check doesn't make sense.

If we start following semver more strictly, and releasing 'minor' versions more often, that means we'll be reaping fewer benefits from our binary compatibility, putting pressure on us to release 'satellite' projects more often, and possibly even releasing multiple version lines of various components. I'm not sure that's the right choice.

[mdedetrich]

By definition of semver patch bump's shouldn't add new functionality, only fix anything thats currently there so on surface level this seems okay

I don't know how strictly we plan to follow semver. For Akka, we've been using it quite loosely, e.g. allowing new features in a patch release, and this has served us well. If we continue down that path, loosening the version check doesn't make sense.

So far with Pekko we have followed it strictly so there shouldn't be an issue if we decide to adhere to it.

The only exception to this is the 1.0.x series where we have been adding migration functionality in patch versions (this is the reason why I was pushing for making the original release 0.x.x and not 1.0.x).

If we start following semver more strictly, and releasing 'minor' versions more often, that means we'll be reaping fewer benefits from our binary compatibility, putting pressure on us to release 'satellite' projects more often, and possibly even releasing multiple version lines of various components. I'm not sure that's the right choice.

So if we decide to follow this strictly this shouldn't impact anything as minor versions are meant to be backwards binary compatible with eachother (which is why new features should only be done in patch bumps as that breaks forwards compatibility and patch versions should be backwards, forwards and source compatible)

What it will do is add extra overhead as we will have a lot more branches to handle (1 branch for every major.minor). We have been doing a good job of automating away this overhead so I don't think it's too much for now but that is largely reflecting the current feature cadence that we have (which is not a lot)

[mdedetrich]

So firstly I would like to apologize for the chaos created, at work we are currently using a snapshot version and then it suddenly stopped working when it was bumped to the latest snapshot version and so my immediate emotional response was "crap, the build somehow broke" and since there are releases open I wanted to prevent a broken release being made, now we know that nothing is broken.

I don't think we should change this (i.e. mix version check), there are reasons why we don't allow mixed versions like this however @pjfanning is right in that the proper way to solve this is by using a bom, sbt does not support this but gradle/maven does.

[pjfanning]

sbt plugin - https://github.com/heremaps/here-sbt-bom