Right now library versions are strings. They look like
The library version string is used by the library manager to detect whether there are updates available or not. I think right now there is no “higher/lower version” detection being done, it simply reports a new version being available if the version name changed.
The question is how to handle that in practice. One option would be Semantic Versioning. But there are two issues with that:
- Library elements should never break compatibility, so there should never be a breaking version increment.
- New library elements could be considered new features, or they could be considered improvements to the current features. Hard to categorize.
To me, SemVer for libraries doesn’t really make sense. The semantics are unclear in the context of libraries. The only important information conveyed is that the library changed somehow.
That’s why I’d propose using incrementing integers instead of version strings. This could also be a convention only, meaning that it’s still a string in the library (avoiding a format update), but the convention is that the integer is simply incremented on changes.
This is both simpler and does not convey semantics where there aren’t any. Furthermore, it could be automated with a tool, e.g. using a GitHub merge hook.
A third option would be to hash the entire library, but I think that’s a bit more complex than it needs to be.