Add release & support policy#54
Conversation
| | Version | Compatible with | | ||
| |---------|-----------------| | ||
| | 1.x | 1.0 ≤ 2.0.x | | ||
| | 2.x | 2.0 ≤ 3.0.x | |
There was a problem hiding this comment.
Should these be 1.0 <= 2.x.y? Or do you explicitly want to be ale to deprecate things in minor releases and then drop compatibility with that in the next major release? That seems a little aggressive to me, but also not entirely unreasonable.
| ### Recommendations | ||
|
|
||
| - Before deploying the next major version (e.g. `v2.0`), ensure all devices have been updated to the latest previous major (e.g. `v1.x`). | ||
| - Before deploying the next minor version (e.g. `v2.1`), ensure all devices have been updated to the latest major (e.g. `v2.0`). |
There was a problem hiding this comment.
I'm worried this might force us to do a lot of 2.0.y releases in parallel with 2.1.y releases.
There was a problem hiding this comment.
Yeah, there's lots of ways to do this. We don't have to do it this way, open to other ideas
The alternative is then we have to make sure that all 2.X releases are compatible with 1.x releases.
If we force folks to upgrade to 2.0 first, that reduces our matrix of testing for the later 2.x releases.
|
|
||
| | Version | Compatible with | | ||
| |---------|-----------------| | ||
| | 1.x | 1.0 ≤ 2.0.x | |
There was a problem hiding this comment.
this should be at least 1.x and 2.0.y as these are no the same variables
|
|
||
| **End of Life (EOL)**: The version is no longer supported. No bug fixes, security updates, or maintenance will be provided. Continued use is at the customer's own risk, and upgrading is strongly recommended. | ||
|
|
||
| | Release | Full Support | Maintenance Mode | Extended Support | |
There was a problem hiding this comment.
I think we need to frame this a bit differently, we will provide full support for the latest version, eg 1.5.3 and not 1.0.0 for this time
3 participants
No description provided.