Third-Party Software Version Management Policy

During system upgrade and reconstruction, third-party software conflict is the most common issue. With the rapid development of software iteration, the traditional software compatibility management policy is no longer suitable for the development of software.

This section describes the best practices of third-party software management to help you build a continuously evolving application system.

1. Software security vulnerabilities cannot be handled in a timely manner. The discovery and exploitation of security vulnerabilities take a certain period of time. If the earlier version is used for a long time, security vulnerabilities are more likely to be exploited, making the system more vulnerable to attacks.
2. When the system is faulty, it is more difficult to seek community support. Versions that are no longer maintained or have been released for more than half a year can hardly be supported.
3. System evolution becomes more difficult. When new features need to be added to the system and new development tools need to be introduced, it is more difficult for earlier versions to be compatible with the new development tools.
4. Many faults may have been rectified in later versions, and the code maintainability and performance of later versions are better than those of earlier versions.

Therefore, the best solution to open-source software selection is to select the development or maintenance version provided by the community for maintenance and upgrade, drive the upgrade to the latest version based on the issue, and periodically upgrade to the latest version every quarter.

• POM of project X

  <dependency>
    <groupId>groupA</groupId>
    <artifactId>artifactA</artifactId>
     <version>0.1.0</version>   
  </dependency>
  <dependency>
    <groupId>groupB</groupId>
    <artifactId>artifactB</artifactId>
    <version>0.1.0</version>   
  </dependency>

• POM of project A

  <dependency>
    <groupId>groupC</groupId>
    <artifactId>artifactC</artifactId>
    <version>0.1.0</version>   
  </dependency>
• POM of project B

  <dependency>
    <groupId>groupC</groupId>
    <artifactId>artifactC</artifactId>
    <version>0.2.0</version>   
  </dependency>

When project X is finally released, the following situations may occur:

• Version 0.2.0 of project C is used. Because project A is compiled and tested using version 0.1.0, component A may not work properly. For example, version 0.2.0 is incompatible with version 0.1.0, and project A uses these incompatible interfaces.
• Version 0.1.0 of project C is used. Because project B is compiled and tested using version 0.2.0, component B may not work properly. For example, project B uses the new interfaces provided by version 0.2.0.

If the interface of component C used by project A is incompatible with that used by project B, project X cannot work properly no matter how the interface is adjusted. The code of project A must be modified and tested using the same or compatible version as that of project B. A new version must be released for project X.

Therefore, the best policy for dependency management is to ensure the dependency of common components and use a later version. However, there are often a number of issues, especially when the project dependencies are very complex.

Currently, the dependency management mechanism is used to manage the dependency of mainstream complex projects. Dependency management has been proved to be an effective method for managing dependencies and therefore is widely used in open-source communities. For example, for Spring Boot, Spring Cloud, and Spring Cloud Huawei, you can view the source code directory structure of Spring Cloud Huawei to learn about how to use dependency management.

For a complex project, for example, the Spring Cloud Huawei project, the POM file related to dependency management includes:

/pom.xml # Root directory of the project.
/spring-cloud-huawei-dependencies/pom.xml # Main dependency of the project . All the statements related to the dependency management are in this file.
/spring-cloud-huawei-parents/pom.xml # parents is used by sub-modules of the project and project developers, which is similar to the parent provided by Spring Boot
/spring-cloud-huawei-bom/pom.xml # BOM is used when project developers expect to introduce the components provided by Spring Cloud Huawei into the dependency management of the project instead of introducing the third-party software versions on which Spring Cloud Huawei depends.

The POMs of Spring Cloud Huawei are relatively complete. They provide developers with POMs that can be introduced from different perspectives and are applicable to common development components.

Generally, a microservice development project may contain only the /pom.xml file. The parent and dependency management of the project are declared in the /pom.xml file. After dependency management is introduced, all dependency statements in the project do not specify the version number. In this way, when the third-party software version needs to be upgraded, you only need to modify dependency management in the /pom.xml file.

You can use the Spring Cloud Huawei samples to understand the principle and function of dependency management:

1. Run the mvn dependency:tree command to check the project dependency.
2. Modify spring-boot.version in the /pom.xml file and run the mvn dependency:tree command to check the dependency relationship changes of the project.
3. Adjust the positions of spring-boot-dependencies and spring-cloud-dependencies in the /pom.xml file, and run the mvn dependency:tree command to check the dependency relationship changes of the project.

When the number of third-party software on which a project depends increases, it is difficult to identify the mapping between software. In this case, you can follow the version mapping of Spring Boot and Spring Cloud. It is a good choice to use spring-boot-dependencies and spring-cloud-dependencies as the basis for dependency management. Because Spring Boot and Spring Cloud are widely used, the community can fix compatibility issues in a timely manner. Developers only need to upgrade Spring Boot and Spring Cloud versions and do not need to pay attention to the versions of other third-party software on which Spring Boot and Spring Cloud depend.

Upgrading third-party software can promote continuous software improvement, but engineering capabilities, such as automatic test capabilities, need to be improved.