Proposal for the handling of Wrappers -- some in the repo, others outside

[swcurran]

Per the AnonCreds Rust Working Group meeting of 2022.11.07, on the topic of Wrappers for the Rust artifacts:

• It would be nice to have generated wrappers if they are of sufficient quality and consistent with the Rust model (which may not be possible). Stephen to talk to Steve McCowan about what generated wrappers would be like to see if the rest of the Devs are supportive.

Let's assume (for now) that generated wrappers are not viable. If we are going have hand-crafted wrappers, where do we put them -- in this repo or have them as a separate repo?

Argument to keep them in

• we can make them a GHAction test to be working before merges
• we can make a GHAction produce release artifacts in-sync when tags are created.
• more likely to keep them up to date
• helps with core feature testing as wrappers are part of the repo vs. an external dependency

Argument to move them out

• unmaintained wrappers become a burden and making releasing features harder.
• Having them in a separate repo can make them easier to update (although that should really not be the case as long as we have active, engaged maintainers).

Proposal:

• Keep core, active wrappers in this repo
  • with named maintainers
  • with GHA tests
  • GHA artifact generation/publishing
• Non-core (no active maintainers) are in separate repos
  • Any non-core wrapper repo that is not maintained for a designated period (suggest 6 months or 1 year) will be archived.
• Policy and process for moving a wrapper into or out of the main repo
  • Suggest:
    • Create issue (optionally with a PR)
    • Posted proposal on Discord
    • Notification to contributors to wrapper
    • Meeting, discussion and vote of the maintainers
  • After the decision is made, the wrapper will be moved into or out of this repo.
    • If moved out, minimal work would be done by maintainers to create a new non-core repo with the wrapper
      • It must have the code and GHActions, but the GHAs do not have to be functional.
• Keep "WRAPPERS.md" file with list of active wrappers, maintainers and policies.
• Suggestion for initial wrappers meeting criteria are:
  • Python
  • Javascript
  • We'll ask the AF-Go team if they want to keep the golang wrapper in the repo
  • We'll ask the .NET team (@CHempel-esatus ) if they want to support a wrapper in this repo

[swcurran]

@TimoGlastra @andrewwhitehead @blu3beri @dkulic -- let me know if you have strong feelings about this "split" approach of some wrappers in the repo and other wrappers outside. Does anyone prefer either all in or all out?

Thanks

[dkulic]

I agree with the proposal.

[genaris]

I think it is a very reasonable proposal considering where we are and concerns from previous experience, as mentioned in yesterday's call with indy-shared-rs (@andrewwhitehead needing help to properly evaluate a wrapper for a platform he doesn't have access to) and indy-sdk (with a separate react-native wrapper as @TimoGlastra mentioned).

It seems to me that separate repos for wrappers could work better for technologies that the core team do not manage or use for testing frequently. Otherwise, it will be nice to have it in the same repo and force their update on each release.

Also this makes me wonder on a potential confusion for wrappers stored in separate repos: imagine a Java wrapper, would it be called anoncreds-java? What if someone else writes a pure Anoncreds Java implementation? Not our problem now, but would be nice to be clear on that.

[swcurran]

I was thinking it would anoncreds-wrapper-java, or if needed anoncreds-rs-wrapper-java.