Branch strategy for sustainable feature development

[yizha1]

Currently Notation v1.0.0 release is blocked by branding issue. While fixing the naming issues and it will take some time, the feature development for v1.1.0 release should continue. The proposal is to create a release branch release-1.0 based off the main branch per release management, so that v1.1.0 feature development can be unblocked. This branch release-1.0 is also used for patch releases (bug fixes for 1.0.0 features or security issues) in later phases. What I am not sure is how to handle the version file and the 1.0.0 tag of main branch.

We should create a branch strategy document including but not limited to this strategy for sustainable feature development.

/cc @priteshbandi @iamsamirzon @shizhMSFT @toddysm @FeynmanZhou @sajayantony for comments.

[yizha1]

What we discussed is to address the following scenario:

All the code and documentation for a release are merged into the main branch. It is ready to cut a release from main. However, the release is blocked for other issues not related to the release scope, for example, branding issue blocks the Notation v1 release.

The solution is to create a release branch, so that new features can be developed continuously in the main branch.
The detailed how-to is addressed by notaryproject/notation#713