Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename repository to sapphire #353

Open
tjanez opened this issue Aug 20, 2024 · 5 comments
Open

Rename repository to sapphire #353

tjanez opened this issue Aug 20, 2024 · 5 comments
Assignees
Labels
docs Documentation

Comments

@tjanez
Copy link
Member

tjanez commented Aug 20, 2024

It would make sense to rename this monorepo from "sapphire-paratime" to just "sapphire" (i.e. https://github.com/oasisprotocol/sapphire-paratime/ -> https://github.com/oasisprotocol/sapphire/) and call the product Oasis Sapphire. Then in the text, where appropriate, it can be shortened to just Sapphire.

The thing that would be still be called Sapphire ParaTime would be the actual runtime inside the runtime/ directory.

We would need to go through the code in the repo and see where we need to rename things from sapphire-paratime to sapphire and where they should stay sapphire-paratime.

@aefhm aefhm added the docs Documentation label Aug 20, 2024
@aefhm
Copy link
Contributor

aefhm commented Aug 20, 2024

Very much agree with the rename.

@matevz
Copy link
Member

matevz commented Sep 24, 2024

I am slightly against breaking the -paratime convention for the runtime repos. But we could split the sapphire-paratime repo into:

  • sapphire-paratime: just the runtime, same format as cipher-paratime, emerald-paratime, keymanager-paratime, pontusx-paratime etc.
  • sapphire-sdk: everything else (clients, contracts, docs, examples)

If monorepos are a bad idea, we could have more of those:

  • sapphire-paratime
  • sapphire-contracts
  • sapphire-js (monorepo also containing hardhat, viem, wagmi and examples)
  • sapphire-py
  • sapphire-go
  • sapphire-docs

@aefhm
Copy link
Contributor

aefhm commented Sep 24, 2024

I am slightly against breaking the -paratime convention for the runtime repos. But we could split the sapphire-paratime repo into:

  • sapphire-paratime: just the runtime, same format as cipher-paratime, emerald-paratime, keymanager-paratime, pontusx-paratime etc.
  • sapphire-sdk: everything else (clients, contracts, docs, examples)

➕ to the split preserving the monorepo for al the clients and tooling. I'm cool with a separate sapphire-paratime repo or embedded in the monorepo.

@tjanez
Copy link
Member Author

tjanez commented Sep 26, 2024

I am slightly against breaking the -paratime convention for the runtime repos. But we could split the sapphire-paratime repo into:

  • sapphire-paratime: just the runtime, same format as cipher-paratime, emerald-paratime, keymanager-paratime, pontusx-paratime etc.
  • sapphire-sdk: everything else (clients, contracts, docs, examples)

Yes, that is also a good idea.

I would suggest:

  • renaming the current sapphire-paratime repo to sapphire-sdk
  • extracting the runtime/ParaTime parts (i.e. the runtime/ directory, GitHub Actions workflows, ...) along with git history to a new repo named sapphire-paratime

If monorepos are a bad idea, we could have more of those:

  • sapphire-paratime
  • sapphire-contracts
  • sapphire-client-js (monorepo also containing hardhat, viem, wagmi and examples)
  • sapphire-client-py
  • sapphire-client-go
  • sapphire-docs

I see something like this possible in the future. Another naming convention for the "clients" could be:

  • sapphire-sdk-js
  • sapphire-sdk-py
  • sapphire-sdk-go

@kostko
Copy link
Member

kostko commented Sep 26, 2024

Another important thing to consider is the runtime releases which are linked from various places and should remain valid at all times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation
Projects
None yet
Development

No branches or pull requests

4 participants