libyang-cpp and sysrepo-cpp branching strategy

[dpward]

Let's adjust the branching strategy in the libyang-cpp repository please, so that:

• libyang-cpp's master branch depends on libyang's master branch tip or older; while
• libyang-cpp's devel branch depends on libyang's devel branch tip or older.

Similarly for the sysrepo-cpp repository, let's adjust it so that:

• sysrepo-cpp's master branch depends on sysrepo's master branch tip or older; while
• sysrepo-cpp's devel branch depends on sysrepo's devel branch tip or older.

I am using Rousette, but the current branching strategy makes this unnecessarily difficult. Thanks for these adjustments.

[jktjkt]

Hi there, we won't be doing that. At @CESNET, these repositories are maintained by a different team with a different workflow, a different understanding of API/ABI guarantees, and ultimately a different set of deliverables. The TL;DR version is that the C++ bindings "always" track the devel branch of the C projects -- unless the C++ team is busy adopting to some change upstream. If that happens and the C++ bindings start to lag by, say, more than a week, then the required version of the C projects is described in the README of the C++ ones.

We currently do not have the resources to maintain multiple versions of the C++ libraries, and we bump our SOVERSIONs a bit more aggresively compared to the C projects. If we offered another branch as you suggest, that might imply that we actually provide support for these older versions -- which is not the case.

[dpward]

It would help to stop and consider how someone outside of @CESNET is supposed to install the latest version of Rousette, to be very specific. Right now this process is rather convoluted, because of the way libyang-cpp depends on a version of libyang that isn't actually tagged in the repository. We need that to be addressed.