Closed evan-forbes closed 1 year ago
We use this repo for both the optimint and celestia forks of the cosmos-sdk
That might actually be the biggest source of confusion. Both Celestia and Optimint use two different base branches, that may be updated independently, yet the default branch in the repo is for Celestia. What are our thoughts around splitting up this repo into cosmos-sdk-celestia
and cosmos-sdk-optimint
, that can each have their own project-centric default branches, release cycles, etc.? cc @liamsi @tzdybal
John and I discussed this offline. We agreed there should be distinct branches for the Cosmos-SDK version used for Celestia-App and the version used for Sovereign Rollups that use Optimint.
I like the idea of separate repositories to remove confusion.
You cannot fork a repo twice in same organization - it is not possible to make new repo that is a fork of original cosmos/cosmos-sdk
in celestiaorg
organization.
You cannot fork a repo twice in same organization - it is not possible to make new repo that is a fork of original cosmos/cosmos-sdk in celestiaorg organization.
You can, however, fork celestiaorg/cosmos-sdk
in celestiaorg
, which should achieve the same goal.
It looks like Rollkit maintains https://github.com/rollkit/cosmos-sdk so perhaps this issue can be repurposed to document just the branches used by celestia-app. AFAIK that's currently only release/v0.46.x-celestia
but we should also document main
.
I added a README in https://github.com/celestiaorg/cosmos-sdk/pull/356 that describes release/v0.46.x-celestia
but it's not clear to me what main
is for. @cmwaters what upstream branch does main
track? What is main
's purpose in this repo?
Not documenting main
and instead deprecating it in https://github.com/celestiaorg/cosmos-sdk/issues/359
We use this repo for both the optimint and celestia forks of the cosmos-sdk, and to make it even more confusing we have important feature branches based on both of those (qgb, smt). We don't have good documentation as to which branches are used for what other than the names of the branch.
We should document the purpose, base, and status of each branch and keep it handy, perhaps even include this in the readme