raptorjit release version confusion

[tst2005]

Hello,

I made test between raptorjit 1.0.0 and 1.0.3.
I got source from git using corresponding tags.

After install I was surprised to discovered a bin/raptorjit-1.0.0 in my 1.0.3 path.

The version was not updated into the Makefile.
I don't know you approach about patch release (major.minor.patch named by semver)
If you don't really care about the patch number, I recommend you to make changes to install a bin/raptorjit-X.Y instead of bin/raptorjit-X.Y.Z or put a "x" instead like bin/raptorjit-1.0.x.

The tags v1.0.1 and v1.0.2 are also affected.

Regards,

[lukego]

Good catch!

Do you want to make a pull request that sets the name to raptorjit-1.0 in the Makefile? Then we can update that on larger releases.

[tst2005]

@lukego I miss lot of time. TL;DR Unfortunately the fix seems more complicated than only the binary install path.

I take a look about the others:

• PUC-Rio Lua mainly use major.minor but we can see the exact version (with the patch number) in interactive mode or in the lua -v.
• LuaJIT mainly use a full strict major.minor.patch versionning (even in libluajit).
• RaptorJIT herited from LuaJIT is currently also mainly oriented to use a strict major.minor.patch.

IMHO,

1. The binary installation path can be changed bin/raptorjit-X.Y instead of bin/raptorjit-X.Y.Z without particula problem
2. The internal version information, shown on the interactive mode, by raptorjit -v, or present in the jit.version and jit.version_num should be use the full strict major.minor.patch.
3. The name of the shared lib produced should probably continue to follow the major.minor.patch chain.

IMHO, After investigation even if we can simply the binary path, we should continue to internaly use a strict versionning.
The current case is a bug and we should work to fix it and find a way to avoid it in the futur.

• Is there a way to update the version during the tag process ?

Regards,