Deprecate single-segment top-level namespace

[piotr-yuxuan]

Single-segment top-level namespaces are hard to manage with native compilation.

For more context, see clj-easy/graalvm-clojure#51 (comment)

As a suggestion I updated the version number, but I leave the final choice to the maintainers.

[KingMob]

@piotr-yuxuan

This is quite a big change, unfortunately, and I really don't like the duplication. Realistically, few people upgrading will notice they need to change namespaces, which means keeping copies in sync forever. One alternative is to move the code, but expose it in the original namespaces. Elsewhere, borkdude suggested sunsetting the old ns, and only making updates in the new ns, which I'm also not a fan of, since people won't notice upgrades do nothing for them. It may be better to use new project names (e.g., byte-streams2), but that's a bit weird for a project in maintenance mode.

Regardless, I'd like to hear more about the situation with GraalVM, and why it can't handle single-segment namespaces. Can they actually not be included, or is it just that it's tedious to list them out as they have no package? How big an issue is this?

[KingMob]

OK, after chatting with borkdude, I don't think it will be so bad.

However, if we're going to do this, I'd prefer to place primitive-math under clj-commons with byte-streams. I can introduce you to the clj-commons admins if you want to be the maintainer for primitive-math, or I can deal with it myself. Let me know which you prefer.

[KingMob]

Closed by #54.