Switch to SemVer versions

[nikolay]

Is it possible to switch versions of OpenResty and modules to SemVer?

[agentzh]

@nikolay Nope. We use our own versioning scheme. Given that I'm already maintaining so many opensource projects, I don't want to bother thinking too much about version numbers. Well, they are just numbers.

[amingilani]

@agentzh is it possible for me to convince you otherwise? Containers are becoming a popular way to orchestrate production images, and the convention is that is that if we base our container files off of 1.12 it will always link to the latest 1.12.x without breaking backwards compatibility.

If you don't plan on doing so, could you atleast tell users how your scheme works, so that we don't end up breaking compatibility during upgrades? :)

[agentzh]

@amingilani We do have an official documentation section explaining how our version schema works:

http://openresty.org/en/faq.html

We won't break any backward compatibility in the minor dot releases. For example, 1.11.2.4 is strictly backward compatible with 1.11.2.1. Well, actually, we seldom or never break API level backward compatibility. We take this very seriously. So it shouldn't be an issue at all.

[nikolay]

@agentzh Why don't you at least use the SemVer convention, i.e. major.minor.patch+build, i.e. 1.11.2+04 using the above version? Unfortunately, the build number should be 0-padded.

[agentzh]

No, at least it breaks backward compatibility and breaks exiting tool chain and packages. We cannot afford such chaos. This issue is closed. I'd spend my time on something truly meaningful and important.

[amingilani]

Yeah, I for one agree. It's too much work for too little reward. Especially since they match the first three version numbers with nginx which does use semver.