Packer doesn't follow semantic versioning

[twalker1998]

Hi,

I looked through community resources, and couldn't find a discussion about this. Please direct me to any discussions I might have missed.

In Packer version 1.10.0, certain plugins were removed from Packer core. I don't have any objections to these removals- ultimately I agree that these plugins shouldn't be shipped with Packer core.

However, my team uses Packer in a completely airgapped environment, and all new software (i.e. Packer plugins) must be approved by our security and legal teams, which is a long and arduous process.

We were forced to upgrade the version of Packer we use from 1.8.x to 1.10.x due to CVEs we discovered in 1.8.x, which broke a number of pipelines that utilized the Amazon and Ansible plugins. This package upgrade did go through the review process mandated by our security and legal teams, but the breaking change was missed, as this was a minor version change. We are now stuck in a holding pattern until our security and legal teams review the usage of the plugins that were removed.

Could we downgrade to 1.8.x? Sure, but that opens us up to a number of CVEs. Should we have validated that upgrading to 1.10.x had no breaking changes? Absolutely.

My question is though- considering breaking changes to Packer were clearly introduced in a minor version release, is it safe to assume that Packer is not following semantic versioning? And if semantic versioning is not being followed, is there any documentation that explains the versioning strategy that Packer is using?

[github-actions]

Hi 👋 thanks for reaching out.

For general questions we recommend reaching out to the [community forum](https://discuss.hashicorp.com/c/packer) for greater visibility.
As the GitHub issue tracker is only watched by a small subset of maintainers and is really reserved for bugs and enhancements, you'll have a better chance of finding someone who can help you in the forum.
We'll mark this issue as needs-reply to help inform maintainers that this question is awaiting a response.
If no activity is taken on this question within 30 days it will be automatically closed.

If you find the forum to be more helpful or if you've found the answer to your question elsewhere please feel free to post a response and close the issue.

[nywilken]

Hi @twalker1998 thanks for opening up this issue - this is a topic that has been brought up before and agree that it is time that we document it. I've opened a thread internally to get Packer's versioning documented and posted on the developer.hashicorp.com/packer.

That said, I will take the opportunity to answer your questions to hopefully give some clarity on how versioning works for Packer and some of the other HashiCorp products. As I understand your point on upgrading between minors does not signal a breaking change.

My question is though- considering breaking changes to Packer were clearly introduced in a minor version release, is it safe to assume that Packer is not following semantic versioning?

Major version bumps at HashiCorp are a big deal and don't happen that often. A major like 2.0 for Packer would indicate a compatibility change to Packer, specifically how Packer communicates with its plugins or strides in how templating works.

For cases like 1.10 and soon 1.11, we are changing how plugin loading works to help correct pain points. Packer and plugins will continue to work as they do today but will require changes to user workflows.

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.10+ 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.

I hope this answer provides you with the information you need. If not please drop a comment on the thread and we will gladly find a way to work it into the final versioning documentation.