On Thu, 12 Mar 2015, Will Cosgrove wrote:
As time allows I will be committing some of the updates we've made over the
years, but I was wondering what to do about commits that break binary
compatibility. Should we (you?) create a 1.6 branch to commit bigger
changes to? For example, the known hosts error values I submitted yesterday
could live there.
I have some opinions on the matter.
I don't think we should take breaking the ABI easily. We should only break it
if we REALLY need to. Applications and distros don't like it - understandably.
Users will like us more knowing that we have a solid API and ABI.
Then, I think each potential breakage should be discussed here to see what to
do about it. Maybe we can come up with a way that won't break existing apps?
Maybe we deem the new think not worth breaking the ABI. Maybe we think the
idea is worth bumping the soname for!
The known host error code change you posted
(https://github.com/libssh2/libssh2/pull/3) is in the category I would qualify
as nice-to-do but not needed enough to break the ABI due to this. So once we
do get a bigger change we think it _is_ worth breaking the ABI for we can
merge that change too.
I don't think we should branch off anything at this point since maintaining
several branches is a lot of work.
Furthermore, I have sha256 kex support but is also binary incompatible.
How and why is that binary incompatible?
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
