search

emscripten-core / emscripten

Emscripten: An LLVM-to-WebAssembly Compiler
Other
25.83k stars 3.31k forks source link

Create versioning policy for emscripten #19053

Open sbc100 opened 1 year ago

sbc100 commented 1 year ago

We should decide if we even plan to use the major or minor version numbers again in emscripten or if we want to simply continue to use patch versions.

If we are going to drop major and minor bumps should we just move so a single number the chrome and firefox do it?

Split out from discussion in https://github.com/emscripten-core/emscripten/pull/18191#issuecomment-1480173774

sbc100 commented 1 year ago

@tlively @juj @kripken @dschuff

Thomas has made that argument that there is quite of benefit in being able to compare two version and get a good idea of how far apart they are in time. For example with Chrome its obvious that v88 is 12 versions older than v100

I've never been a huge fan of semantic versioning myself, so I'd been keen to drop the pretense that that is what we are doing, and admit that there is no such things as a patch-only, risk-free upgrade. I think a single monotonic version is easier to reason about and its also what we have been doing anyway for almost all our emscripten releases to years ( we just happen to have been using the patch level as this number).

tlively commented 1 year ago

I like semantic versioning a lot, but we don't do it and it wouldn't be feasible to start doing it as far as I can tell. I agree that it would be better to avoid giving the impression that we do use semantic versioning. I don't feel strongly about whether we do that via documentation or a change to the version number format.

curiousdannii commented 6 months ago

One option is to simply use the date as the version number.