Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

from terraform-provider-cloudflare.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

from terraform-provider-cloudflare.

we follow semantic versioning. the breaking change you are referring to was a field that has not been used in 5+ years, has never been configurable by an end user and has been the default value for all records for even longer. the read process for data sources should already be taking this into account. if it doesn't please file a bug with the reproduction steps to get it triaged.

from terraform-provider-cloudflare.

we follow semantic versioning. the breaking change you are referring to was a field that has not been used in 5+ years, has never been configurable by an end user and has been the default value for all records for even longer.

Either it is a breaking change or it isn't. If you don't believe it is a breaking change, then don't label it as such. If it is a breaking change, and you're following semver, then it should be a major version bump.

Semver is a tool to communicate the nature of changes in an update. You can choose to use it, or you can choose not to - either choice is valid. If you choose to use it, then you do it because you believe that your users can benefit from the information that it conveys, and that it is worth the extra effort it requires from you.

A major version bump is not something that should be avoided at all costs; it is a way to help your users by pointing out that there are breaking changes in the update that might affect them. If the breaking changes are trivial, then that's great - it's an easy upgrade, and your users will be happy.

Shipping a breaking change in a minor version bump is dishonest. Tools trust the information and rely on it. When you break that trust, you also break those tools, and the processes that depend on them.

I'm not asking you to stick to semver, nor that you stop using it. Simply be clear about your choice, and stick to it. The worst you can do is to be unclear about it.

from terraform-provider-cloudflare.