Replies: 1 comment
-
Thank you for your feedback. The SDK is currently in experimental status, with some breaking changes planned for the future. For now, I plan to release SDK v1.0 after these changes. Once v1.0 is reached, compatibility will be as guaranteed as possible and releases are based on semantic versioning. See also #1693 However, the current plan is that the end of support for past SDK versions may occur with a minor update to TFLint. I believe that given the 6 month grace period this shouldn't be an issue as it is generally preferable to always have the latest SDK and TFLint running, but I'd be interested in hearing your opinion. What do you think? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Introduction
We've been using tflint for a while now and has been a smooth ride up to now. For different reasons, the tflint version was pinned to an older version. We also have a custom rules plugin. When we updated dependencies of the plugin, the api used was bumped but the tflint executable that uses it was not... and then everything broke even though no major major versions of tflint had been released. With that said, a minor release of tflint could have exposed a new api while being backward compatible. Although, the SDK did not get its major version upgraded as well when removing support for older tflint versions. Going through the releases, there are notes of breaking changes here and there, pretty well documented.
Proposal
Adopt semantic versioning for releases version of tflint and its plugin sdk in order to better communicate impact of new releases.
Beta Was this translation helpful? Give feedback.
All reactions