I thought I’ll make this thread for all of you out there who have questions but are afraid to ask them. This is your chance!
I’ll try my best to answer any questions here, but I hope others in the community will contribute too!
I thought I’ll make this thread for all of you out there who have questions but are afraid to ask them. This is your chance!
I’ll try my best to answer any questions here, but I hope others in the community will contribute too!
Why in Linux, Software uses a particular version of a library? Why not just say it’s dependent on that library regardless of version? It become pain in ass when you are using an ancient software it required old version of newer library so you have to create symlinks of every library to match old version.
I know that sometimes newer version of Library is not compatible with software but still. And what we can do as a software developer to fix this problem? Or as a end user.
Because it’s not guaranteed that it’ll work. FOSS projects don’t run under strict managerial definitions where they have to maintain compatibility in all their APIs etc. They are developed freely. As such, you can’t really rely on full compatibility.
IMHO the answer is social, not technical:
Backwarts compatibility/legacy code is not fun, and so unless you throw a lot of money at the problem (RHEL), people don’t do it in their free time.
The best way to distribute a desktop app on Linux is to make it Win32 (and run it with WINE) … :-P (Perhaps Flatpak will change this.)
Update the software to ensure it works with the latest version of the library or rewrite it using a different library that maintains backwards compatibility.
Edit: To clarify a little further, windows typically does this by including the needed libraries with every application (dll files) so you end up with many copies of the same library because every app brings their own version.
Linux doesn’t do this traditionally, but you can package your own libraries (including old out of date libraries, the issue is they’re typically insecure and have security fixes added after those versions) with your apps by using one of the new all in one package management systems like Flatpak or God forbid, snap.
Software changes. Version 0.5 will not have the same features as Version 0.9 most of the time. Features get added over time, features get removed over time and the interface of a library might change over time too.
As a software dev, the only thing you can do is keep the same API for ever, but that is not always feasible.
To add some nuance, all features in v0.5.0 should still exist in v0.9.0 in the modern software landscape.
If v0.5.0 has features ABC and then one was then changed, under semantic versioning which most software follows these days then it should get a breaking change and would therefore get promoted to v1.0.0.
If ABC got a new feature D but ABC didn’t change, it would have been v0.6.0 instead. This system, when stuck to,helps immensely when upgrading packages.
When having a breaking change pre 1.0.0, I’d expect a minor version bump instead, as 1.0.0 signals that the project is stable or at least finished enough for use.