SemVer for elasticsearch-dsl

With 6.2.0 release I’ve suddenly realised that dsl in not following semver (minor version introduced backward-incompatible changes).

I thought that semver is accepted for all products under elastic umbrella, at least starting from “synchronized” releases (when all ELK stack rolls out with same versions). Isn’t this a thing? Or dsl is not supported by this level of effort — as not an official client?

[msholty-fd]

@HonzaKral I think having 4 digits on your version isn’t going to fix the issue. I would recommend just being very clear in the documentation what the versioning means. Most people assume that if you have versioning like x.y.z, it’s SemVer, and are confused when it’s actually not.

Why does the documentation recommend installing such a broad range, like elasticsearch-dsl>=6.0.0,<7.0.0? Maybe that is a good start, but once you pip install elasticsearch-dsl>=6.0.0,<7.0.0, you should check to see which version was actually installed and then lock it down by putting an actual version number in your requirements.txt like elasticsearch-dsl==6.2.0

[honzakral]

Thank you all for feedback, it makes perfect sense and I have to apologize again for the incompatibilities 6.3.0 brought in a minor version.

While there are technical tools to pin dependencies (and I do highly recommend that for production) that is no excuse to break people’s code. I didn’t make the decision lightly but I felt it was warranted given the amount of changes and fixes that became available in 6.3. Going forwards I will be even more cautious in introducing breaking changes outside of major version.

If I ever decide that it is required to introduce backwards incompatible changes (outside of severe bug fixes and possible security patches) I will consider just breaking the elasticsearch version sync instead.