Spring Cloud finally changed
Recently, Spring Cloud changed the version number of London Underground stations from A to Z to be named with dates.
- https://spring.io/blog/2020/04/17/spring-cloud-2020-0-0-m1-released
That is, from the style of Greenwich.SR6, Hoxton.SR9 to the form of 2020.0.0. The masses of people finally don't have to worry about the version number of Spring Cloud.
Spring Cloud is not well promoted, although it has its own complicated reasons, and the version number is too complicated is also a pit.
The date is the version number, the so-called Calendar Versioning, you can refer to this website:
- https://calver.org/overview_zhcn.html
When to use CalVer
If you develop a project with a lot of people you don’t know, then using a rigorous version naming method is a suitable choice, and CalVer happens to be one of the choices.
Does the project have a large or constantly changing scope?
- Large systems and frameworks, such as Ubuntu and Twisted.
- A collection of practical tools without actual boundaries, such as Boltons.
Is the project time sensitive? Are there other external changes that drive the release of new versions of the project?
- Business needs, such as Ubuntu's support plan.
- Security updates, such as certifi's need for certificate updates.
- Political changes, such as pytz's handling of time zone changes.
If you answer yes to any of these questions, CalVer can be a powerful choice for your project.
But I think these reasons are not sufficient.
In my opinion, the most important reason is: using the date as the version number allows the developer of the dependent library and the downstream relying party to reach a tacit agreement.
Alibaba's practice
Pandora is an isolation container inside Alibaba. In 2014, the Pandora package version number was like this:
- 2_1_0_3 , 2_1_0_4_10-LOG
Change to Pandora version + date later
- 2_2_140825, 2_2_140905
But in fact, the application side does not care about the version of Pandora, so it changed to the current style:
- 2020-04-release-fix , 2020-10-release
Benefits are:
- Promote upgrades by time nodes
E-commerce businesses are all time-critical nodes, such as 618/Double 11. The middleware and the application side have reached a tacit agreement: At a critical time, the business side uses the stable version of the middleware. If there is an accident, it is the middleware's pot. Do not upgrade, it is the business side's own pot. - The resistance to upgrade is reduced.
When the business side encounters a problem, it is natural to think of the upgrade when the version number is more than a year ago. - Relying on the provider to keep updated on time. Maintainers
themselves must continue to release versions to prove their vitality. Downstream users can also choose whether to switch to other new technical routes based on time.
For some overall dependencies, such as the maven bom inside the company, it is recommended to use time as the date.
For example, Spring 2.5.6 version, most developers know that it is an older dependency, but there will not be much motivation to manage it.
But if you say that this is the code 12 years ago (most of the development has not graduated), then the developer knows that incompatibility problems are prone to occur, and he himself knows that he should upgrade.
Taking time as the version number is not only a promise to users, but also a spur to developers themselves.
Reader benefits
Thank you for seeing here!
I have compiled a lot of 2021 latest Java interview questions (including answers) and Java study notes here, as shown below
The answers to the above interview questions are organized into document notes. As well as interviews also compiled some information on some of the manufacturers & interview Zhenti latest 2021 collection (both documenting a small portion of the screenshot) free for everyone to share, in need can click to enter signal: CSDN! Free to share~
If you like this article, please forward it and like it.
Remember to follow me!
