New Roadmap for Ursa

[appetrosyan]

After several meetings and deliberation with @hartm et al, we settled on the following interim plan for the version 1.0

• [ ] Update all dependencies, handling semver incompatibilities. (#225, TBD)
• [ ] Replace fail with anyhow and std::error::Error-based workflows.
• [ ] (Optional) only if easy, provisions for no_std.
• [ ] (Optional) Provisions for plugging into miette and more informative error handling projects
• [ ] Removal of feature gates for optional components. LTO is much better at eliminating unused code. The shared object produced must always include every algorithm.
• [ ] Plugin system, such that algorithms are fully self-contained crates. This allows depending on these crates directly for faster compile times, simplifies feature testing, and ensures that algorithms are sufficiently decoupled.
• [ ] Refactoring + linting + CI improvements.
• [ ] CD for multiple packages and architectures. Consider using Aries runners for Apple silicon (aarch64 with x86 extensions, without SVE).
• [ ] extern C, WASM, node, Python (PYO3) and Java interop.

[appetrosyan]

@mikelodder7 I don't want to break the codebase too much, so I would appreciate your input before I begin executing on this plan, particularly in relation to feature gates.

[swcurran]

Not sure if this fits at the level you are talking, but CI that produces artifacts to enable creating container images targetting multiple architectures — including ARM — would be helpful. A CI that enables a trivial change to automatically produce new release artifacts is important.

[mikelodder7]

This proposal is similar to the one I have in mind. Maybe it doesn't need to be here, but a provision for language wrappers like c_ffi, wasm, node, python, and java as needed. Not sure if we need no_std having done a lot of it myself. The no_std rule should be if it doesn't complicate things then fine do it, otherwise it should be optional.

[mikelodder7]

@swcurran not sure those artifacts are helpful except in the language wrapper case. Also if we're separating primitives individually, and you want a single library that only contains what you need, that requires a separate CI per configuration. Something to keep in mind.

[appetrosyan]

I've updated the roadmap with the proposed tasks. We should be able to get these done relatively soon.