Consider adopting semantic versioning

[Martin Meinhold]

See https://semver.org/ for details about what semantic versioning means.

We have built some automation that tries to keep libraries on the latest minor version. Trying to update Confluence from 1.2.2 to 1.5.1 resulted in a compile error like ...

TestValidationReport.java:[28,19] com.atlassian.swagger.enforcer.TestValidationReport.TestMessage is not abstract and does not override abstract method withAdditionalContext(com.atlassian.oai.validator.report.ValidationReport.MessageContext) in com.atlassian.oai.validator.report.ValidationReport.Message

This means a minor update now requires a human to look at which over time makes those updates too time consuming for us and hence requires us to stop doing that for libraries like the swagger-request-validator.

It would be highly appreciated if you could follow the rules of semantic versioning and announce breaking changes with a major version bump.

Cheers

[James Navin]

I do attempt to follow semver.

The change there was additive and was explicitly done in a way that would not break existing consumers of the API. TBH I had not expected to see implementations of that interface outside of the SRV lib.

If you extend/implement the interface then yes, you will need to make a code change, but as it is not an SPI I would suggest the onus is on you if you choose to do that...

Regardless, I will endeavor to minimize these sorts of breaks in the future.

[Martin Meinhold]

Oh, interesting. Looking closer I now understand that the usage in Confluence indeed uses ValidationReport from core which it should not do. It has its own implementation so it can deserialize some data via

final ValidationReport validationReport = new ObjectMapper().readValue(responseMock.getContentAsByteArray(), TestValidationReport.class);

Either way, I lack too much knowledge in that area to fix it so I'll leave it as it is. Thanks again for the quick feedback, I'll mark this issue as resolved.