Core Specification Release Workflow

[ravi-prakash-v]

Currently we have a master branch that tracks all releases of the core specification. the latest release is 0.9.3. We have a draft branch core-0.9.4-draft for tracking all new features in the next upcoming release.

This approach seems to have a few issues.

1. Schema changes which are supposed to be included in the minor or major versions also seem to get included in the next version even though the patch version number is only for typos, text changes and extremely minor backward compatible changes.
2. Any hotfix to the specification seems to get blocked until a consensus is achieved by the CWG.

I propose we have a master branch and a draft branch that contain all bugfixes and enhancements in the current version. The Core Working Group can cherry-pick specific commits and create a release branch that is numbered appropriately depending upon the nature of updates and the criticality of release.

@beckn/core-working-group Thoughts?

[pramodkvarma]

I am fine with that idea.

[ravi-prakash-v]

This is done. Have created a draft branch from master and merged the core-0.9.4-draft into this. Going forward, PRs will be made to this branch and based on the urgency of the release, the @beckn/core-working-group will cherry-pick specific commits and then decide the version number instead of the other way round.

The core-0.9.4-draft will undergo a deprecation cycle of one week starting today after which the branch will be decomissioned. An announcement will follow shortly after this post.