Packaging?

[jbergstroem]

Any plans on doing releases of klib? Versioning, tarballing and so on. I'd really like to see changelog notes outside the header files as well.

[attractivechaos]

For now, I do not have plan to properly package klib, partly due to the way it is developed and partly due to the fact that each component of klib is independent of others. Nonetheless, I will leave the issue open here. If more people are requesting packaging, I will probably do that.

[DavyLandman]

I like the current approach, just one file to include :) Nice fast library btw :) Could use some better docs, but hell, that's always the case :)

[theduke]

I wouldn't care about packaging, but versioning is important.

I woud recommend semantic versioning (http://semver.org/).

[martingkelly]

+1 I for one would love packaging. I think a simple package that just installs these the headers into a klib subdir would be super handy.

[solvingj]

There are reasonable arguments for consuming this library as single files on-demand, as well as for consuming it as a package. Doing github releases improves the situation for consumers wanting to use the second approach, while not precluding consumers from using the first.

My team would like to create a package for this library for the Conan package manager. Our standard approach is to use Github releases. The library and resulting package are much less attractive if we don't have a semantically versioned github release/tarball that we can pin to, and increment over time as the components evolve.

[martingkelly]

Releases would be nice, I agree. If there are none, you can also use an auto-incrementing number + a git commit hash as the version. Debian does this for some packages.

[solvingj]

Yes, we have a documented strategy for it here, but as I said, it’s suboptimal for us and consumers.

https://bincrafters.readthedocs.io/en/latest/using_packages.html#packages-without-official-releases