When will 3.2.0 be released?

[msqr1]

I know Emscripten is using semantic versioning, but the patch version is only for bug fixes, we've been adding new features like --use-ports, wouldn't that bump the minor counter? I feel like the patch counter is getting out of hand, it's at 55 now.

[tlively]

Emscripten does not use semantic versioning, even though our version numbers make it look like we do. We usually bump the minor counter when something suitably "big" changes.

[msqr1]

What versioning does it use? What count as a big change, and with this, will the major version ever get bumped?
@tlively

[sbc100]

Right, but because we never go back and patch any existing releases (we only ever fix forward, so to speak) if we applied the the chome scheme we would indeed end up with single number because the other two would always be zero.

[msqr1]

Why not just switch to single number right now, if the other 2 numbers don't have any use?

[sbc100]

That is a good question, and one I think we should consider.

The discussion in #15917 has not concluded so I think we should think a little more on it.

[msqr1]

For a single version number though, what if a really big change land, we bump it by 2,3? And changing the versioning system like this, we have to define a new macro like EMSCRIPTEN_VERSION, and that would make this in itself a breaking change for people testing downstream.

[sbc100]

I'm not sure how we would define "really big change". We don't currently have any such definition. I guess we did this one in the entire history of the project when we went from fastcomp to llvm backend. But even that was supposed to be an un-observable change and should have been non-breaking for most folks. So it was a really big internal change really.. not a really be external/breaking change.

I agree switching to single version would be tricky for reasons such as EMSCRIPTEN_VERSION macros. My guess is that if we do that route we would just use EMSCRIPTEN_VERSION_MAJOR and fix the MINIOR and PATCHversions at zero. However, we are still a long way from deciding to do that I think.

[sbc100]

People know Chrome by that single number, but it doesn't actually use that. https://www.chromium.org/developers/version-numbers/

3.1.XXX

FWIW, hopefully Emscripten would not use 3-digit minor/patch version component, because that could cause issues on downstream projects. For example, with projects that are doing:

if __EMSCRIPTEN_major__*10000 + __EMSCRIPTEN_minor__*100 + __EMSCRIPTEN_tiny__ >= 30156

That seems like a weird assumption to make.. but sure we can try to avoid that.

This code assumes the minor and tiny number can only go to 99 but the major version can go above 99..

[kleisauke]

Indeed, it's a somewhat unusual way to check for an specific Emscripten version at compile time. Some occurrences are:
https://github.com/rust-lang/libc/blob/a0f5b4b21391252fe38b2df9310dc65e37b07d9f/build.rs#L197
https://github.com/mosra/magnum/blob/b1419017650c83538d8fe4681de6f0bca524cf49/src/Magnum/Platform/EmscriptenApplication.h#L77