DEV BRANCHES: Version control - Development - Code Merging

[vncoelho]

Now that all basic components are here in the neo-core, we depend in this repo in different ways.

Without proper UTs, Integration Tests and verification on neo-cli, we will often need hotfix on minor things after a MAJOR release.
In particular, things become too much complex when we need to add new feature or refactors and we still need minor fix on main branch.

In mind of minor fixes, or even major ones, I would like to highlight, at least, the following:

• We are going to still have many problems during the development of future MAJOR VERSIONS without a proper branch control.

Perhaps some commits since 3.7.4 could had been merged in a kind of development branch, while any necessary minor fix would directly go to master.

We could let a PR open with a per-defined title -> DEVELOPMENT BRANCH: NEXT MAJOR 3.X.X

[cschuchardt88]

Benefits of having Release Branch:

You need create a new branch for releases when it time. Not only setting the tag in master. But creating this branch.

1. Will allow us to make any configurations.
2. Will allow us to apply bug fixes.
3. Easy to use and understand github workflow actions.
4. Can be merged back to master. (if any hotfixes)
5. Will allow us not to have releases in nuget. (like v3.7.0, v3.7.1, v3.7.2, v3.7.3, v3.7.4 to just get deleted)

Example branch names would be:

• release/v3.8.0
• release/v3.9.0
• release/v3.10.0
• release/v3.11.0

---

[vncoelho]

Exactly, @cschuchardt88

[cschuchardt88]

Perhaps some commits since 3.7.4 could had been merged in a kind of development branch, while any necessary minor fix would directly go to master.

Normally you have a development branch. Where each member has it own branch; branching off the development branch.