search

MinaProtocol / mina

Mina is a cryptocurrency protocol with a constant size blockchain, improving scaling while maintaining decentralization and security.
https://minaprotocol.com
Apache License 2.0
1.99k stars 529 forks source link

Peel off website into separate repository #6217

Closed nholland94 closed 4 years ago

nholland94 commented 4 years ago

The website does not have any dependencies on internals of the MinaProtocol/mina repository. It's release cycle is currently tied in with the release cycle of the testnet, but this logically doesn't make sense, and has caused issues. Given that we already need to separate it's release from the testnet release cycle, I suggest we move the whole website codebase over to MinaProtocol/mina-website and setup the release cycle and CI separately there.

The main argument I see against doing this is that the docs included on the website should be tied to the release of the testnet, but a potential solution to that could be hosting the docs separately on a docs.minaprotocol.com domain and keep those in the MinaProtocol/mina repo and release cycle.

Arguably, we should do the same for the wallet as well. If we move enough things out of the frontend/ folder, it may also make our frontend-specific CI guards simpler.

bkase commented 4 years ago

The website currently does not have many dependencies shared with the internals of Mina, but it has in the past (the js snark demo) and will in the future (any future js demos and eventually the nonconsensus node).

It does have a shared dependency on the graphql schema (from which we generate the docs) and it has a dependency (though not an automated one yet) on the shape of the CLI.

Currently, the Minaprotocol.com website is deploying off of develop (not master like codaprotocol.com is/was).

I’m not saying we necessarily shouldn’t move it to it’s own repo, but the cons for doing so are larger than you have suggested.

I’m also hoping our ci guards get more fine-grained over time (esp. if bazel becomes our primary path for builds).

nholland94 commented 4 years ago

The website currently does not have many dependencies shared with the internals of Mina, but it has in the past (the js snark demo) and will in the future (any future js demos and eventually the nonconsensus node).

The js snark demos and the nonconsensus nodes shouldn't be "internal" to the MinaProtocol/Mina repo though. They should be released from MinaProtocol/Mina with the latest version, and then the website can include that release target. This makes sense as the release cycle of the js artifacts should be tied into the release cycle of our general mina node artifacts, but not necessarily tied to every website release. A likely scenario is that we want MinaProtocol/Mina to always point to the most recent snark demos, and if that is the case, we can deploy the js artifacts to a cdn and reference it in the website from there (such that no redeploy of the website is necessary when we publish a new demo version).

The graphql schema and CLI issues I believe are answered by the idea of having a docs.minaprotocol.com site deployed from generated docs that live in MinaProtocol/Mina rather than putting the responsibility of managing and generating that into the website implementation itself (thus tying the release cycles together).

Deploying off of develop helps separate the release cycles for now at least, but I would question that as a long term decision. Seems like we would want a robust process around testing the website in staging after any docs changes in every PR that does so, otherwise we risk pushing invalid docs or docs that don't apply to the currently released version.

bkase commented 4 years ago

The graphql schema and CLI issues I believe are answered by the idea of having a docs.minaprotocol.com site deployed from generated docs that live in MinaProtocol/Mina rather than putting the responsibility of managing and generating that into the website implementation itself (thus tying the release cycles together).

I think this could even go further and we can publish some machine readable representation of our docs (generated automatically ideally) and tie that to releases along with the js code and anything else.

I think we've already lost the idealized monorepo for other reasons so I won't cling to that world for this content. I'm onboard with the plan 👍