Version A.B.C.D:
If the code undergoes such a significant change that the previous version might be continued to be developed indefinitely, increment A. In particular, we are expecting development of the old branch that would that would increment its B value described below. For most projects A will remain constant.
If the API changes in a backwards incompatible way, increment B. B is approximately major version number, but I see it incrementing quite rapidly compared to current practice. We leave undefined what is the API and what is backward incompatible, but for example, for library code, removing just one exported symbol or changing one type signature is backward incompatible.
A major version increment alerts users to test whether they use the affected feature. The speed at which this major version increments might induce packages to split their functionality into smaller packages, providing more stability for a each package.
C is normally zero, but is there just in case there is an unforeseen strong objection to the backward incompatible change in API in version B+1 that a fork develops based on B. The difference between A and C is foreseen versus unforseen forks. This will of course become messy if there are further forks of forks and backports and merges.
For changes that do not affect API in a backward incompatible way, increment D. Despite being the least significant value, this could include major functionality changes and API additions, also a departure from current practice.
No comments :
Post a Comment