< H2 > Semver is used in the application library. < / H2 >

the definition of Semver on the application library is clear and mature

example on application library:

• repair small BUG. Updated with Patch revision.
The
• object adds a method. Minor minor version number is updated.
• Delete method. The Major major version number is updated.

this is widely used in dependency management tools (npm/composer/maven/...).

< H2 > Semver is used in the project < / H2 >

for example, take gitlab as an example. After reading changelog, I feel that the major and minor version numbers change irregularly. It seems to have nothing to do with the change of the project code.
such as: delete code method, did not change the major version number. The version definition of the application library is not applicable.

Project will maintain API in a separate version:

this is understandable.
for example, the original / api/v1/user/1 returns {"name": "Tom", "age": 18}
adding fields, deleting fields, and changing the structure will change the major version numbers / api/v2 , / api/v3

. < H2 > questions < / H2 >

how to apply Semver in a project

• the reference object of Semver in the application library is the change of code, will the reference object of change in the project also be the code?
• does the API of the project need to be defined separately as a version?

• if the reference object is code:

  • how to define a version in the code of UI, such as HTML/CSS changes and no method definition?
  • changes in the configuration of project code have a greater impact. For example, if the source code of Sifou has a switch to configure the "private message" function, and the configuration is changed, does the version need to be redefined?
  • (this also includes questions as an application library) depends on the version upgrade of the library, the execution of compatible code, and the change of the revision number?
    for example: {"jquery": "^ 2"} in npm package.json . {"jquery": "^ 3"} .