Total code version change record

initial version

All editors share a common code with built-in svn

question:

• Every time it is a new module, new function, and compatibility modification, the code structure is very chaotic and not conducive to use
• Not to mention the iterative development of the code, the development of a large number of changes, cannot satisfy all editors to synchronize the development and changes of the common code and submit them synchronously.

solve:

• Each module is managed by version, and there is iterative development to improve the version number. The editor uses the version tool to select the version it needs.

the first edition

Module version management

question:

• It is cumbersome and error-prone to select the module name + version name every time you export code
• And the editor should not care about the association between these module versions

solve:

• Remove the module name selection, and each time the code is changed, the module version configuration file that the current change depends on is generated
• You only need to select the configuration file corresponding to the changes to export directly

second edition

Module version management, users do not need to care about the relationship between
modules Module version configuration can be automatically generated, trunk version automatically merged into release

Question one:

• Every time a small optimization or a small bug is changed, a configuration needs to be generated (trouble)
• If small optimizations are mixed with large iterative updates, we hope to:
  
  • If you want to make a small version, it is easy to update the full editor
  • Major version of each project selection update

Example 1

• There are two versions A and B (big revision), and now there is a bug that needs to be fixed immediately
  
  • bug, based on A
    
    • 1. Mars is using A now
    • 2. Mars is using B now
  • bug, based on B
    
    • 3. Mars is using A now (don't care)
    • 4. Mars is using B now

Current practice: It is more troublesome for 1. The other three are relatively simple
- 1. Generate the C version, update the modification of the BC version synchronously
- 2. Generate the C version, and directly modify the project according to the modification of the C version of the public code Public code commits (hard to control)

PS If the small changes do not need to be used immediately, the configuration can be generated together with the next time

Question two

When the editor modifies the requirements, it also needs to modify the public code. At this time, the public code version includes A, B, and C (the latest)
version A currently used by the editor. How should I change the code if I want to change it?

Current practice:
1. Synchronize the changes of BC, and then generate the D version according to the public code submission code rules and requirements (if there are many versions in the middle, it is very troublesome)
PS: You can force the editor to update to the latest version every Monday.

solve:

像软件更新一样，代码只能由自己（公共代码）更改，每次发型版本+版本改动说明，用户升级时需要做相应的修改（目前的结构刚好符合）

third edition

Use branches to manage public code, create new branches with major version changes, and modify and merge small changes directly on the branch, keeping the number of branches at about 5

Normal project branch management

Common code branch management

• The trunk version remains the latest available version, and development is on the branch
• For minor version changes, submit svn directly on the current branch, and then merge into trunk and all major versions of the branch
• When there is a need for major version changes, open a new branch from the trunk for changes (guarantee the number of branches <= 5, and stop the development of the smallest version when it is equal to 6)

How projects use branches

• Every time you use a new branch as the editor's built-in svn public code, you need to modify it synchronously: this version has incompatible changes (change.md) with the previous version, and submit the new branch and changes together after the test is normal
• The use of branch can only be upgraded level by level, for example:
  
  • There are now branch_001, branch_002, branch_003
  • Newly accessed projects can only use branch_001, and modify incompatibility according to change.md
  • Then upgrade to branch_002, and then upgrade to branch_003