Replies: 1 comment 1 reply
-
|
We have different repos since they must have different review and merge policies, different teams with different access etc. Consensus code is very distinct from system code and application code by its security considerations, and security considerations can be enforced only at the level of a repository. |
Beta Was this translation helpful? Give feedback.
-
|
Also, I expect RGB core to ossify, and RGB std lib not to require a lot of changes - once we have v1 release. So there will be no need for synchronized changes to a bunch of repos right now, when the speed of development before the release is highest. |
Beta Was this translation helpful? Give feedback.
-
Introduction
There are 4 workspaces under RGB-WG,
rgb,rgb-core,rgb-std,rgb-schemata. The rely on each other and share some similar dependencies.Problems
Solution
Create a new repo, and merge current repos as parts into a big workspace, namely, keep the current repo in different folders, such that the code is still loosely coupled.
Each part can be a submodule(or can not be if we don't like submodules), so we can easily use
git submodule update --recursiveto have a whole view of our repos and still possibly use check different branches to know our crate compatibility on our different crates.Advantage and shortage
rgb,rgb-core,rgb-stdorrgb-schemata) will be hard, and all the repoes here are public, so it is not an issue for us.Reference
Wish to have your insight on this. @dr-orlovsky
Beta Was this translation helpful? Give feedback.
All reactions