Cleanup SCM.md

[lubkoll]

Probably the release process should be updated. Plz check.

I am happy to add stuff (back) if needed.

[ajansari95]

I believe the current branching rules for feature and fix segregation are well implemented and should remain unchanged. However, I propose that we introduce a more granular approach to release tagging by segregating them based on chain and contracts relating to a project. For instance, we could use tags such as v1.0.0-chain and v1.0.2-cl, where cl encompasses all contracts related to the CL range middleware, dexrouter, etc. Moving forward, as we develop additional products like LSA, each should have its own dedicated release tag for the associated contracts. This approach will enhance clarity in releases and versioning imo

[lubkoll]

I believe the current branching rules for feature and fix segregation are well implemented and should remain unchanged. However, I propose that we introduce a more granular approach to release tagging by segregating them based on chain and contracts relating to a project. For instance, we could use tags such as v1.0.0-chain and v1.0.2-cl, where cl encompasses all contracts related to the CL range middleware, dexrouter, etc. Moving forward, as we develop additional products like LSA, each should have its own dedicated release tag for the associated contracts. This approach will enhance clarity in releases and versioning imo

Are you talking about git tags? If so, yes, we can use them (though updating a tag on every minor version change is overkill imo -- except if we automate that). How do you currently mark the release state in git?