New ABI breaking LYD_LYB format change needs a major version bump.

[choppsv1]

FRR has been deployed that runs with version 3 of libyang, it uses LYB for inter-process communication. A recent change from 3.12 to 3.13 (?) has made LYB no longer work. This will break all our users unless the libyang major is incremented.

[choppsv1]

FWIW, this major bump could be avoided in libyang if it handled working with older clients by doing something that continued to work for them. I suppose you could use a packed JSON encoding for example.

[michalvasko]

Essentially, I want users to find out there were changes to use them and provide feedback (which is exactly what is happening). And we can skip the argument whether this change requires a version bump or not this time because the devel branch already has SO v4 prepared, which should be released in the next few weeks.

[choppsv1]

That is perhaps a reasonable thing for the development branch (along with some actual warning to developers!), but unless i'm mistaken you released this code. It's pretty much not reasonable for your user's users (our end-users) to do something like apt upgrade and have their routers fail in order for libyang to get developer feedback. :(

[choppsv1]

Are you at least considering pulling the release? This is going to break our users -- people that are skilled in debugging network issues, not semver violations deep inside the software they are using.

[michalvasko]

How do you pull a release? In any case, I think you simply have unrealistic expectations. At least in our case, we really are not able to guarantee full backwards compatibility in the sense that you understand it between the same major version releases. We don't change the API/ABI, which is fairly simple to track but the conformance of any other changes is decided on a best-effort guess.

I seem to remember we have discussed a possible solution for this problem, which would be you having a CI script that would run FRR tests on every libyang devel push. That way you can immediately identify any breaking changes affecting you and we can fix those before the changes are released. Not sure why this does not work already but is not my responsibility.

[choppsv1]

An FRR compiled against libyang v3, the user does an apt upgrade (or whatever) libyang v3 updates to the latest release and the installed FRR breaks.

It's literally the definition of making a non-backward compatible change. We've been around in circles on this before -- it's really frustrating.

We really appreciate the excellent engineering in this project, but the version nonsense that breaks our users unnecessarily is frustrating (never mind the arguments over it).

As far as how to pull a release, just delete the release from the list of releases under github -- that's how i've done it when I made a mistake with e.g., munet.

[michalvasko]

Fine, I have made a re-release of the latest version that should parse the LYB data just like before. The new version in devel will have a different SO version so it should be okay. I hope that settles this issue.