-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update CHANGELOG #12877
Update CHANGELOG #12877
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
for the note on the breaking change, if following semantic versioning shouldn't the next release be 2.0 vs 1.11? |
Hi @Stromweld, I didn't want to merge without responding first. Thank you for bubbling up this question. Major version bumps at HashiCorp are a big deal and don't happen that often. A 2.0 for Packer would indicate a compatibility change to Packer, specifically how Packer communicates with its plugins or strides in how templating works. That is not the case here - we are changing how plugin loading works to help correct pain points. Both Packer and plugins will continue to work as they do today. I understand your point on how 1.11.0 does not signal a breaking change. Given that Packer is an application and not a library or SDK we follow semantic versioning a bit loosely by allowing for the introduction of breaking changes in minors. Historically, Packer has bumped the minor version when removing deprecated components and introducing breaking changes like the ones in 1.11.0. When possible, we provide the necessary tooling to help mitigate the blast radius of the workflow changes. We recommend that users check the CHANGELOG before upgrading to any release to understand how changes may affect their workflows. The breaking changes in 1.11.0 are specific to user workflow changes, which contain deprecations and some that are just downright confusing with the introduction of features going back to 1.7.0. We are releasing 1.11.0 as an alpha to get early feedback. We've also updated our documentation for plugin developers in the packer-plugin-scaffolding repository to help align future development with the direction of the Packer plugin loading strategy. I hope my response helps you understand why we are working towards 1.11.0 over 2.0. |
Thanks for the explanation. Of course every company has their right to version as they see fit, I was just more asking out of curiosity and to better understand what's in a version change for the packer project. That makes a lot of sense and is very understandable. Thanks again for the thorough explanation. |
You're welcome @Stromweld. Glad the explanation helped. Thanks for continuing to contribute to Packer. |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
No description provided.