Discussion on version control policies in software products

Our company has been engaged in software products for more than 10 years. Therefore, the product version must be well controlled.

 

As a not-big software enterprise, of course, it cannot be like Microsoft's Windows or Apple's Mac OS. When the maintenance cost is higher than the version replacement cost, you can consider changing the version. Generally, each version is valid for 3-5 years. It will not be maintained after 5 years. Our company's previous strategy was to have a major version, that is, a major version, and many branch versions, that is, patch versions. Multiple versions are developed and maintained in parallel. When the branch version has common application requirements or functional points, you can consider porting it to the main version. This not only maintains the versatility and Stability of the Main Line version, but also has a certain degree of continuity.

 

The current problem is that the demand for major versions has been well developed and there are few major changes. However, there are many projects to be implemented, and there are also many individual needs to be developed. There may not be too many things that can be ported to the main line version. However, if the pace of the major version is slowed down. When will the branch version be closed? When will the main line version be used? How can the branch version control the quality well? These are all prominent issues.

 

Analyze the problem:

If you try to adopt a one-to-one approach, one branch version corresponds to one project. User satisfaction should be the highest, but the cost is also the highest.

If the one-to-N method is adopted, there may be a problem. When a project requires a different project, this requirement may lead to some column defects, these defects should not have occurred in other projects. This will inevitably affect user satisfaction. However, the development cost will be reduced.

 

Bold ideas for solutions:

So the best solution should be to classify similar projects into a branch version as much as possible, and do 1-to-1 for totally different projects. In this way, the product manager's capability requirements are relatively high.

At the same time, for a one-to-N project, there must be a planning document to describe the name of each project and the reason for merging it into a branch version. It is best to review the planned changes through the change process. In addition, when a project in multiple projects is completed, you need to complete the project on the branch version, in parallel, this branch version is used as the baseline, and a new branch version is generated to continue the development of the remaining projects.

 

Policies for the main line version:

Because the main line version is almost stable, there is no major change. You can consider the following strategies:

1. Control by time, such as releasing a major version in one year. Strict control of time points cannot be delayed, but the range can be adjusted flexibly. However, you must ensure sufficient testing time to ensure the quality of the major version release. The advantage of doing so is that the requirement or defect can be added at any time and is not restricted by the project boundary (the change request is not required for the project boundary change ). The disadvantage is that the project cycle is long and the project boundary is unknown (completely controlled by the Project Manager ).

2. Use regular project management to collect requirements and determine boundaries. If the boundary meets certain conditions (for example, the development workload reaches 6 months), version development will be conducted. The advantage of doing so is that the project boundary is fixed and the project completion time is controllable. The disadvantage is that the project change is difficult.

According to the current product features, I suggest using policy 1.

 

I wrote a lot about it myself. It feels like talking to yourself. I hope you will have better comments and suggestions. Exchange and learn from each other.