raylib so versioning with 3.0.0 release

[jubalh]

You are naming the shared objects files:

/usr/lib64/libraylib.so.2.6.0
/usr/lib64/libraylib.so.261

Are you sure about this for the 3.0.0 release?

[raysan5]

@jubalh yeah, I know, I have to re-release it...

[raysan5]

re-released! :)

[jubalh]

Should that really be /usr/lib64/libraylib.so.301?
Before we had:

libraylib.so.2                                                                                                                                                                
libraylib.so.2.5.0

Which looks good to me. Like any other project I'm aware of does it too. But not sure why we would want 301 instead of 3.

[raysan5]

@jubalh actually that's how it was configured in CMake by @a3f.

I can't remember the logic behind it right now...

EDIT: Actually CI system failed and I need to launch it again...

[jubalh]

It would be good if you do not remove the 3.0 tag once you tagged it and apply it to another commit.
People pull from that tag, create tarballs for distribution and try to include it in Linux distros.
They will end up with different states in such a case.

If you realize something needs to be fixed it would be good to create a new tag and release then. So 3.0.1, 3.0.2 etc.
Otherwise all systems that depend on you will get confused.

I think we have had three different commits tagged as 3.0.0 now, and even drafted as release ;)

[raysan5]

@jubalh Oh, sorry, there are problems with raylib.dll on Windows and I'm working on them to release a fully working 3.0. Is it possible to wait for a while before pulling tags? Or it is an automatic process?

[jubalh]

Yes I stopped the pulling. But it would be better practise to just tag it as beta release or increase the last number :)
Since it might be that others rely on the tag too (from who we don't know and who maybe don't check the bug tracker).

[raysan5]

@jubalh is it ok if I keep the release and tag but I update the attachments? It's a problem with the Windows DLL building...

[jubalh]

Well just do as you like :)
Please ping me here once everything is finished, then I'll update :)

[raysan5]

@jubalh Current raylib 3.0 release is final, I'm not deleting or re-tagging it.

Just note that raylib-3.0.0-Win64-mingw.zip attachment dll is not working properly and I'll try to re-upload that attachment at some point.

[jubalh]

Okay but in case you change anything, for exmaple the so name. Please create a new tag and dont remove/add the 3.0.0 one. Because I will submit to official repos now.

[raysan5]

@jubalh ok, no worries.

[a3f]

Should that really be /usr/lib64/libraylib.so.301?

It should be libraylib.so.300 for the release and after the tagging, it should be libraylib.so.301, so binaries linked against the release raylib aren't accidentally paired with a development or later released raylib this may be incompatible.

Like any other project I'm aware of does it too. But not sure why we would want 301 instead of 3.

Every raylib release adds breaking changes, so we will be incrementing the number on every release anyway.

Instead of counting up and ending up with raylib.so.16 for raylib.so.4.2, I decided just multiplying by 100 is the most readable, because it can be easily mapped to the official release versions.

[jubalh]

Every raylib release adds breaking changes, so we will be incrementing the number on every release anyway.

If this is the case then it makes sense.

[jubalh]

BTW are the API breaking changes documented somewhere? This would make it much easier for developers to migragte from one raylib version to the next.

[raysan5]

@jubalh CHANGELOG details all the functions added, removed or reviewed