Instead of {MAJOR}.{MINOR}.{PATCH} we want to switch to a temporal convention: {YEAR}.{MONTH}.{RELEASE_NO}
This would mean that 1.10.0, if released today would be 26.05.1. This better aligns to the nature of these ever evolving APIs and can solve for some of the complex backwards compatibility issues that we keep running into.
Every release will be tied to the supported versions of the software at that point in time. This should mean that should breaking changes occur in APIs, or GraphQL queries, that we can tie to these new queries, note that within the changelog, and deprecate support for those older versions without having to manage complex backwards compatibility shims.
This should also support increased momentum as we can offer support for the APIs within alignment to the products themselves.
Instead of {MAJOR}.{MINOR}.{PATCH} we want to switch to a temporal convention: {YEAR}.{MONTH}.{RELEASE_NO}
This would mean that 1.10.0, if released today would be 26.05.1. This better aligns to the nature of these ever evolving APIs and can solve for some of the complex backwards compatibility issues that we keep running into.
Every release will be tied to the supported versions of the software at that point in time. This should mean that should breaking changes occur in APIs, or GraphQL queries, that we can tie to these new queries, note that within the changelog, and deprecate support for those older versions without having to manage complex backwards compatibility shims.
This should also support increased momentum as we can offer support for the APIs within alignment to the products themselves.