Improve Branch Management Strategy

[Wi1l-B0t]

Problem Statement

Currently, the branch management workflow follows this pattern:

1. New features are merged into dev branch
2. dev is then directly merged into master

Issues with current approach:

• This branch management model lacks practical significance
• New content merged into dev is merged into master without proper verification
• The goal of ensuring all new features and changes are validated before release is not achieved

Proposed Solution

New Branch Management Strategy

1. Feature Development Flow

• New features should be merged directly into master
• master branch serves as the main development branch and continuously accepts new features

2. Release Branch Creation

• After periodic intervals, create a release branch from master (e.g., release-v3.9-rc)
• Once created, the release branch becomes independent and no new features are added to it
• master branch continues to merge new features independently

3. Release Branch Validation Process

Release branches must go through a comprehensive validation process before actual release:

1. Functional Testing

   • All functional test cases must pass

2. Performance Testing

   • Performance benchmarks must be validated

3. QA Validation

   • Testers must complete their validation cycles

4. Testnet Deployment

   • Must run on testnet for at least 2 months before release

5. Final Release

   • After successful validation: release-v3.9-rc → release-v3.9

4. Bug Fixes and Maintenance

• If bugs are discovered, critical fixes that must be merged should go into:
  • The most recent release branch(es) still running in production
  • Some fixes need to be:
    • Merged into master (for future releases)
    • Cherry-picked to the most recent 1 or 2 release branches (for current production releases)

Benefits

1. Clear separation between development and release cycles
2. Proper validation of all features before production release
3. Stable release branches that only receive critical fixes
4. Continuous development on master without blocking releases
5. Extended testnet validation ensures production readiness

Example Workflow

New features should be released smoothly, rather than all at once.

master (continuous development)
  │
  ├─→ release-v3.8 (Running in production)
  |     |-> Only Hotfixes are merged into this branch
  |
  │
  ├─→ release-v3.9-rc (created from master)
  │     │
  │     ├─→ Testing & Validation (2+ months)
  |     ├─→ Only critical fixes are merged into this branch
  │     │
  │     └─→ release-v3.9 (final release)
  │
  └─→ (master continues with new features)

[vncoelho]

Looks good to me, I also agree with you that the dev has no meaning. In particular, if we later just merge it to master without proper verification of all commits.

Your model is like what we used to work in the past.

I believe it is the way we gonna work again from now on, of course, with better improvements on release branches as you described.

[Wi1l-B0t]

I believe it is the way we gonna work again from now on

Neo had this kind of mode before?
But I haven't seen any release branch, only release tags.

[shargon]

Exactly @Wi1l-B0t , this is the idea, the current PRs should be moved to master.

[Wi1l-B0t]

Exactly @Wi1l-B0t , this is the idea, the current PRs should be moved to master.

The recent features have not been merged into master, only into master-n3.
Why?

[shargon]

Exactly @Wi1l-B0t , this is the idea, the current PRs should be moved to master.

The recent features have not been merged into master, only into master-n3. Why?

Which ones?

[Wi1l-B0t]

Exactly @Wi1l-B0t , this is the idea, the current PRs should be moved to master.

The recent features have not been merged into master, only into master-n3. Why?

Which ones?

The features in dev.

[shargon]

Exactly @Wi1l-B0t , this is the idea, the current PRs should be moved to master.

The recent features have not been merged into master, only into master-n3. Why?

Which ones?

The features in dev.

What features? Dev was merged into master, I don't understand you

[Wi1l-B0t]

Exactly @Wi1l-B0t , this is the idea, the current PRs should be moved to master.

The recent features have not been merged into master, only into master-n3. Why?

Which ones?

The features in dev.

What features? Dev was merged into master, I don't understand you

https://github.com/neo-project/neo/commits/master/

Not include commits in dev.

[ajara87]

there was a PR to merge dev in master #4261

[shargon]

@neo-project/core

As I talk with @erikzhang, all should be merged to master except #4278, this will go to master-n3.

The process will be:

• All to master.
• Before release 3.9 rebase master-n3 from master and merge Exec Factor with decimals #4278.
• After 3.9 we will have two main branches, master for neo4 and master-n3 for neo3.
• Some pr will be duplicated if its required, to master and to master-n3.

[Wi1l-B0t]

Done