What type of versioning is used?

[fegbers]

Hi,

Because we had already some upgrading issues by introduced breaking changes (although documented via the relase notes), i'm interested in what type of versioning is used. Currently i'm thinking you're using Semver. Therefore also the problems with updating…
Perhaps anybody can help me.

Thanks & Greetings

[scordio]

Major versions depend on different Java versions:

• 1.x requires Java 6+
• 2.x requires Java 7+
• 3.x requires Java 8+
• 4.x will require Java 17+

Minor versions usually provide new features but potentially also breaking changes, while patch versions are mostly about bugfixes.

[EarthCitizen]

@scordio

While I respect your right to not follow semantic versioning, and the admirable fact that you document breaking changes, might I suggest a different system for the AssertJ version? The reason being is that, as semantic versioning is so widely used, the majority of people, when seeing N.N.N are going to assume major.minor.patch according to semantic versioning. One would have to do research, as I did, to understand that AssertJ doesn't use semantic versioning. And I suspect that most of your upstream consumers also might not be aware that what appears to be a minor version upgrade can actually be a breaking change.

For example, when upgrading from Spring Boot 2.5.x to 2.6.x, the version of AssertJ goes from 3.19.x to 3.21.x. When in a project of dozens of third-party dependencies, no one has the time to research every one to verify that semantic versioning is being used. Most people would assume binary compatibility in this case, when in fact, AssertJ 3.19.x to 3.20.0 is a breaking change. And in my case, as Spring Boot makes this upgrade, probably without even realizing that it is not backwards compatible, this breaks a third-party library that I am using that relies on ListAssert methods that were removed in 3.20.0.

Another aspect that is confusing about the AssertJ versioning system is that there is not a visual indication if the change will be breaking or not. One needs to research to understand this. As you stated Minor versions usually provide new features but potentially also breaking changes, it is not possible to know which of these two cases it is based on visual inspection of the version, and I feel confident that most would not define "minor version change" as something that could contain a breaking change.

While I am not going to suggest to you that you need to use semantic versioning, I will suggest an alternate versioning system that will satisfy your need for an "epoch" of minimum Java version, and separating breaking changes from new features.

I suggest a 4-segment version:
<min-java-epoch>.<breaking-change>.<new-feature>.<bug-fix>

Such a versioning system would:

1. Provide the needed visual indication of minimum Java version
2. Provide consumers, by seeing 4 segments, the visual indication that semantic versioning is not being used
3. Provide consumers the visual distinction between a breaking change and a new feature

I believe that I understand why semantic versioning is not a fit for you. Hopefully, this type of versioning would satisfy the needs of the project while simultaneously avoiding confusion by consumers.

[scordio]

Thanks for the feedback, @EarthCitizen, we'll discuss your proposal internally.

You mentioned:

And in my case, as Spring Boot makes this upgrade, probably without even realizing that it is not backwards compatible, this breaks a third-party library that I am using that relies on ListAssert methods that were removed in 3.20.0.

What library is that? Is it included in the Spring Boot dependency management?

[joel-costigliola]

Which removed method are you talking about? I don't recall we removed anything and we usually don't remove but deprecate instead.

[EarthCitizen]

@scordio org.hibernate.validator:hibernate-validator-test-utils:6.2.0.Final

@joel-costigliola In trying to give more exact details about the error I was seeing, I did some more digging.

Here is the code from the library that is giving the NoSuchMethodError:

List<PathExpectation> actualPaths = new ArrayList<>();

for ( ConstraintViolation<?> violation : actual ) {
    actualPaths.add( new PathExpectation( violation.getPropertyPath() ) );
}

Assertions.assertThat( actualPaths ).containsExactlyInAnyOrder( paths );

So, when called as part of the compiled JAR with 3.21.0, it generates this:

java.lang.NoSuchMethodError: 'org.assertj.core.api.ListAssert org.assertj.core.api.ListAssert.containsExactlyInAnyOrder(java.lang.Object[])'

That library works with 3.19.x. In 3.20.0, what I noticed that I did not notice before is that containsExactlyInAnyOrder was moved from ListAssert to another class. When I take the code above, and copy it into a test case, it executes with no problem. So, it seems that, even though containsExactlyInAnyOrder is available in a superclass in 3.20.x+, for libraries compiled with 3.19.x, the JVM is unable to locate it? I don't know the complexities of why this would happen, but this is what I found.

[scordio]

Unfortunately, 3.20.x and newer are binary incompatible with 3.19.0, probably the version used by that version of hibernate-validator-test-utils.