nisse@lysator.liu.se (Niels Möller) writes:
For (3), I think Camellia is borderline. It's been implemented in Nettle for a couple of releases, but I expect few applications use it. And I should also add that applications using nettle_camellia* from nettle-meta.h (and do so in the documented way) are unaffected by this change.
One way to confirm theories around which applications uses what is to establish a list of significant applications that uses Nettle, which can be recompiled with a proposed nettle release to see if they break. For you to do this is a lot of work, but maybe just establishing a list of applications which deserves to be tested against newer nettle is useful -- then you can ask for volunteers to actually do the testing, and summarize results. If nobody steps up for a particular application, then that particular project has a weaker rationale to complain about any problems later on. If projects not on the list complains about API/ABI breakage, the project can be added to the list.
The above is just an idea, based on my experience with API/ABI breakage in libraries. I started out believing that the best approch to API/ABI rigidity was to do the right thing from a theoretical point of view -- i.e., if there is ABI breakage, bump ABI -- but I've become more pragmatic over the years. It seems to cause less problems for everyone if you make sure the API/ABI is reasonable and works for the majority of well-maintained packages, even if that sometimes means violating the theoretical rules around API/ABI version bumping. The theoretical rules around API/ABI bumping causes friction and work for a lot of people every time they are excercised, and overall sometimes that can be contra-productive.
/Simon