I know it is probably a subtle / insignificant thing in comparison to everything else about this project, but it is a good thing to do, especially for the sake of communicating various aspects of the library (API, ABI etc) and the stability from the PoV of authors and maintainers.
Something like semver would be a good, widely understood, versioning scheme to consider. Combine that with git-flow and it will make things easier to manage. At least that is the summary of what I have tried with other projects.
It for sure, will benefit anyone integrating with the library, looking for a later, stable version, without having to scan through the commit history to find the git-hash to freeze at.
I know it is probably a subtle / insignificant thing in comparison to everything else about this project, but it is a good thing to do, especially for the sake of communicating various aspects of the library (API, ABI etc) and the stability from the PoV of authors and maintainers.
Something like semver would be a good, widely understood, versioning scheme to consider. Combine that with git-flow and it will make things easier to manage. At least that is the summary of what I have tried with other projects.
It for sure, will benefit anyone integrating with the library, looking for a later, stable version, without having to scan through the commit history to find the git-hash to freeze at.