Daniel Kahn Gillmor dkg@fifthhorseman.net writes:
In short, i don't think an SONAME bump is functionally necessary just for introduction of versioned symbols, though lack of an SONAME bump may introduce some cosmetic changes for people who don't rebuild against the newer version.
And in this case, I think the cosmetic problem is less important, since I'd expect most users to upgrade from 2.7.1 to 3.1, and never install 3.0. But I guess, for the same reason, another soname change should also be relatively painless. Do you agree?
Hmm. So if we conclude that it really would make a better interface with extended base64 contexts, we could do that and bump the soname.
(And API changes are a different matter, I think it is important to not break existing source code using base64. So the idea is that code using base64_init and friends should only need a recompile to work with nettle-3.1).
Does anyone know if applications are using base64_encode_raw, despite it's status as undocumented?
in the debian project, it looks like there are code examples from aria2 that use base64_encode_raw, and it's also used in rtmpdump's librtmp:
Thanks for looking this up. Seems like we should keep (and document?) base64_encode_raw unchanged. And we then have to come up with a new name for a base64_encode_raw_with_alphabet function.
And doing a similar search for base64_encode_group luckily gives no matches at all, outside of nettle.
Regards, /Niels