Next tag/release plans

[birunts]

Hi,

are there any plans to make next tag/release?

We would need new tag or release who contains 9f2d63162e82d423faeda9c7449d6edd819e4591, to make it work directly with Bazel & Bazel Central Registry.

Thanks!

[AgentD]

Hi @birunts ,

in the master branch, I have started to move as much as possible of the re-usable utility code into libsquashfs, with the goal to have a high-level API for composing images in an eventual 2.0 release. I would advice against releasing a random commit from master in a downstream repository. It already breaks ABI/API compatibility in it's current state, and is bound to eventually do so again.

The work on master has been slowing down and somewhat stalling recently, and there are some commits in there, that I think people would want. So I back ported most of them to an 1.3 branch off of the 1.2 release back in March. Some fixes that were overlooked are part of an 1.3.1 release that I published earlier today.

Please use that release instead (signed tag: v1.3.1), it is ABI compatible and contains requested features and fixes since the 1.2 release.

Greetings,

David

[birunts]

Hi @AgentD,

Thanks for quick replay and new 1.3.1 tag. Will use it and we'see if everything we need is there :wink:

Just a question, any reason why the library version does not conform the tag version? libsquashfs.so.1.4.1 -> tag 1.3.1

[AgentD]

Just a question, any reason why the library version does not conform the tag version? libsquashfs.so.1.4.1 -> tag 1.3.1

Because this is a library ABI version, not to be confused with the version of the package.

The package version 1.3.1 follows semantic versioning, which should be fairly straight forward, i.e. major version is 1, 3 means the 3rd feature level upgrade without breaking backwards compatibility, the final 1 meaning a patch level release containing fixes (roughly speaking).

The problem is that, on the one hand, this lumps up both the package and the library, on the other hand, library versioning has different requirements for indicating API/ABI compatibility.

The shared library uses the libtool versioning scheme, which is a little bit more complex than plain, semantic versioning.

For the 1.3.1 release, the libsquashfs libtool version is 5:1:4. The fields are called "current", "revision" and "age". Roughly speaking, current = 5 means, the library implements the 5th iteration of the ABI/API, age = 4 means it implements the interfaces of the last 4 versions, i.e. down to 1, because the interface was only extended from then on. But it is no longer compatible with version 0 that shipped with the pre-1.0 release of the package, because some of the interfaces were removed. The 1 in the middle (revision) corresponds to internal changes that do not affect API/ABI.

From the SO version, libtool computes the version extension of libsquashfs.so. IIRC the first digit is current - age and it just happens to work out as 1.4.1, which is suspiciously similar to the package version (hence the confusion).

The installed binary package contains a symlink libsquashfs.so pointing to the actual library. This is used at compile time, so the command line option -lsquashfs works. The actual library uses ELF meta data to identifying it as libsquashfs.so.1 (soname field), so the compiled program has libsquashfs.so.1 as a dependency.

At runtime, libsquashfs.so.1 is loaded, which in turn, is a symlink that points to the actual library that implements this interface version. If the package is updated, a new library is installed and the symlink is updated. If the versioning scheme was followed, old programs still work as-is, without recompilation.