|
| 1 | +# CalVer Releases |
| 2 | + |
| 3 | +Devtools projects are released with [CalVer](https://calver.org/) scheme version numbers. |
| 4 | +The particular scheme we are using is `YY.MM.MICRO`, meaning that a release in |
| 5 | +March 2025 will be named `25.3.0`, and if a patch (ie, non-feature) release is |
| 6 | +required for that release, it will be named `25.3.1`, even if it is released in |
| 7 | +April. The month will not increment until a new version with features or other |
| 8 | +significant changes is released. |
| 9 | + |
| 10 | +Because of the date-based approach, feature releases of this sort happen on a |
| 11 | +regular cadence which depends on the project but is between every month and |
| 12 | +every three months. |
| 13 | + |
| 14 | +As this is currently a new scheme, care should be taken to ensure that releases |
| 15 | +increment the month and year properly. No release should increment the most |
| 16 | +significant section unless it takes place on a different year than the previous |
| 17 | +release, and a release that happens more than one month after the previous release |
| 18 | +should take care to increment the second most significant section of the version |
| 19 | +appropriately. |
| 20 | + |
| 21 | +Because this scheme eschews semantic meaning to the version numbers, extra care |
| 22 | +should be taken at release time that the changelog is complete and appropriately |
| 23 | +categorized. |
| 24 | + |
| 25 | +- Deprecation notices should be added to the changelog as soon as they are |
| 26 | + agreed upon. The deprecation cycle cannot start before the deprecation has |
| 27 | + been announced. |
| 28 | +- Changes should be properly categorized so that users can see at a glance what |
| 29 | + kind of changes are to be expected. Breaking changes should be clearly called |
| 30 | + out and announced well in advance to limit surprise, as version bounding is no |
| 31 | + longer possible. |
0 commit comments