Open BurningEnlightenment opened 2 years ago
This relates to #67. In that issue, I remarked that I consider it a reasonable thing for a base64
library to claim the base64
namespace. I am still partial to that opinion, although I also understand where you're coming from. Claiming a widely used prefix is not very social behavior when it comes to the kind of multi-tenant environment that vcpkg seems to be working in.
You're correct that I'm considering making some breaking changes for the next release. (Though if I do so, that release will probably be 1.0.0rc1
or 0.99.x
and not 0.6.0
, to indicate through the version number that there is an API discontinuity.) In that process, I would really like to overhaul pretty much everything in this library, and maybe renaming the library might be a nice crown on top of that work. No better break from the old than to start fresh under a new name.
The question remains, if we're going to rename it, what would be a good name? I'd like to include base64
or b64
somewhere in the name so that the library is easy to find.
I'm tending towards akbase64
as a pretty short and reasonably memorable name.
Sounds good to me 👍
During the review of the vcpkg integration of this library (microsoft/vcpkg#25091) it was noted that the name of this library is very generic and will likely clash with other base64 libraries. This is especially dangerous for names resolved by the linker like the so/archive name and function names. The public header name is also prone to a file name conflict.
Therefore it would be nice if either the library name was changed to something more unique like a proper name or the entities above were prefixed with something unique. Obviously this would be a breaking change and I would understand if this was rejected. OTOH it has been mentioned that 0.6.0 would be the target for breaking changes anyway.