search

sysrepo / sysrepo-cpp

C++ bindings for the sysrepo library
BSD 3-Clause "New" or "Revised" License
6 stars 5 forks source link

Git tags? #20

Open andrei-pavel opened 5 months ago

andrei-pavel commented 5 months ago

Could sysrepo-cpp benefit from versioning just like sysrepo does, specifically in the form of git tags, but, less importantly, maybe also in CMakeLists.txt and in github releases?

The lack of git tags forces use of commit ids like specified here which feels risky because the commit might not point to a stable variant. Much like, for example, one would prefer to use v2.2.73 or v2.2.105 in sysrepo as opposed to any of the 149 commits in between.

If this is more of a rolling release project, and the latest commit is always the most stable, that is understandable.

Versions could still be useful for bug reporting and for posterity in general.

This would also apply to libyang-cpp.

Thank you!

jktjkt commented 5 months ago

I understand the preference for versions/releases and tags, but OTOH we are not promising API/ABI stability in either libyang-cpp nor sysrepo-cpp, and I feel that we would have to end up with version numbers that are essentially just plain integers (no semantic versioning). So far, the incompatible changes made were focusing mainly on C++ "details" liek std::string vs std::string_view or struct layout, but there were also "major" changes caused by the fact that we misunderstood some aspects of libyang/sysrepo, and the C++ bindings were suggesting some dangerous code patterns. Since we do not have stable API, we were able to fix these easily.

Regarding the stability/maturity/robustness of the code, we're always running the latest master internally, and we're picking upstream's devel branches on a roughly weekly basis. Also, any commit to the C++ repos is CI-checked against the then-current devel branches of the upstream projects. When upstream changes some behavior (think error reporting pattern for JSON validation, for example), it might take a few days for us to pick up the breakage and fix our tests, but apart from that, it should be a smooth ride. So the official suggestion is to track the master branch of both libyang-cpp and sysrepo-cpp.

But you aren't the first one to request this, so I guess we will have some version tags for convenience, eventually, but that said, version numbers are overrated :), commits/features should not be merged until they are ready, and the tip of the master is definitely the version to use for these C++ bindings.