search

hashgraph / hedera-protobufs

Authoritative source of Hedera protobufs
Apache License 2.0
39 stars 24 forks source link

Branch per network #16

Open janaakhterov opened 3 years ago

janaakhterov commented 3 years ago

I was thinking this might be a decent idea to have a branch per network.

This might make it more clear what is supported and how to interact with a certain network because as of right now develop contains protobufs supported by testnet, and https://github.com/hashgraph/hedera-protobufs/pull/15 seems to contain what is going to be supported on previewnet. Later, when we do a repo per language for the protobufs it might be nice to support each network protobuf's with their own releases such as: 1.0.10-mainnet, 1.0.10-previewnet, 1.0.10-previewnet. Also, having these different releases will make it easier to determine breaking changes in the SDK's.

Not sure if this is a good idea, but perhaps we shouldn't have a main branch at all, and instead rename it to mainnet so no one would need to switch branches once they've cloned the repo.

steven-sheehy commented 3 years ago

I'm not a fan of the current Git flow branch setup, but I also don't like a per environment branch setup. I find that any time you have multiple copies of data they will inevitably get out of sync. I think since services only has one release per month and we're never working on releases concurrently, just a simple main branch and proper semver tagging should suffice. If a hotfix is needed, a release/0.x branch could be spun off the production tag.

janaakhterov commented 3 years ago

I find that any time you have multiple copies of data they will inevitably get out of sync.

This is true.

I think the large benefit of a branch per network (at least for me) is a clear separation of what is currently supported on a per network basis. This means the branches which e.g. don't support live hashes could remove the live hash protobufs. Previewnet on the other hand would keep the live hash protobuf since its support is a WIP.