docs: Create adr-012-separate-releasing.md

[shaspitz]

Description

See #801 and #1216. This is me documenting the info in issue comments to ADR form

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct docs: prefix in the PR title
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• Confirmed the correct docs: prefix in the PR title
• Confirmed all author checklist items have been addressed
• Confirmed that this PR only changes documentation
• Reviewed content for consistency
• Reviewed content for spelling and grammar
• Tested instructions (if applicable)
• Checked that the documentation website can be built and deployed successfully (run make build-docs)

[p-offtermatt]

I think this seems reasonable in principle, but I don't have the most context to the problem this solves, so I'll leave approvals and a deeper discussion to others. Just added a few comments.

[MSalopek]

Name conflicts with testing ADR which was created a couple weeks ago:
https://github.com/cosmos/interchain-security/pull/1197/files#diff-994d3bd14f7d633c856487d57e3b2c19b7db30879cba99918305d2b7dc604a01

Would you mind changing the number to be adr-012-xx?

[shaspitz]

Name conflicts with testing ADR which was created a couple weeks ago: https://github.com/cosmos/interchain-security/pull/1197/files#diff-994d3bd14f7d633c856487d57e3b2c19b7db30879cba99918305d2b7dc604a01

Would you mind changing the number to be adr-012-xx?

Nice catch, I've changed it to ADR 12

[MSalopek]

I don't understand how this would work in practice, can you walk me through the release process?

This is how I understood this text:

Current version is v5.0.0

We make a statebreaking change on the consumer module that results in v5.1.0-consumer.

The released versions now become: v5.0.0 and v5.1.0-consumer?

Alternatively, are we releasing as v5.0.0-consumer and v5.0.0-provider from the get go?

Can you add a quick visualization (using a basic markdown table) that shows what happens in which scenario so the proposed change can be understood more easily?

[shaspitz]

This explanation should help clear things up 02f8576

[mpoke]

One thing to be noted is that if we release a feature that affects both the provider and consumer, then it may end up in different versions, e.g., ICS v4.3.0-provider and v4.0.0-consumer. That would be a bit annoying, but I don't see any better way to deal with this. IMO, we should go ahead and merge this.

[bermuell]

if I understood well there will be no ICS versions anymore only x.y.z-provider and xy.z-consumer.
In that case it would be good to have a statement about compatibility between versions which can diverge from now on and maybe impact on testing.
From a user perspective, can I get from the versioning of provider and consumer which one 'should' work together?

[shaspitz]

I think in the long term we should assume everything is backwards compatible, similar to ibc-go. In the short term there will be exceptions (like throttling v2), but we can communicate this clearly in the versioning descriptions.

[MSalopek]

LGTM! Thanks for the fixes