[GH-ISSUE #476] minor or patch change for a configuration change? #1216

New Issue

GiteaMirror · 2026-04-16T10:32:21-05:00

GiteaMirror commented

2026-04-16 10:32:21 -05:00

Originally created by @jruts on GitHub (Nov 15, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/476

If we change a piece of configuration in the code, would we then increase the patch version or the minor version?

Do note that this is in a Terraform project so the change is technically a code change (since Terraform is infrastructure as code).

I ask this question because it specifically says that the path version is for bux fixes and this causes confusion.

Kind regards.

Originally created by @jruts on GitHub (Nov 15, 2018). Original GitHub issue: https://github.com/semver/semver/issues/476 If we change a piece of configuration in the code, would we then increase the _patch_ version or the _minor_ version? Do note that this is in a Terraform project so the change is technically a code change (since Terraform is infrastructure as code). I ask this question because it specifically says that the path version is for bux fixes and this causes confusion. Kind regards.

GiteaMirror closed this issue

2026-04-16 10:32:21 -05:00

GiteaMirror commented

2026-04-16 10:32:22 -05:00

@klehelley commented on GitHub (Nov 15, 2018):

In a way, with Infrastructure as Code I would consider the resulting infrastructure to be the final "artifact" that external agents (API clients, etc. -- basically all the end-users of the features provided by the infrastructure being described) must interact with. With that point of view, knowing which version number to bump in not too hard to determine:

The change is strictly internal to the infrastructure being modified, with no impact visible by the external agents => patch
New features are added, but existing external agents can continue to use the deployed infrastructure as if the change never happened => minor
Features have been modified in a way that would break existing external agents, or removed => major

Do note that in thinking this way, what I call external agents are not necessarily the ones concerned by the version you will provide (they may however be interested by the version of the endpoints they use, but that should be managed separately provided the infrastructure includes several independent endpoints). It is the person in charge of applying the Terraform plan to a given environment (and may have to intervene were any issue to happen within it) that will be interested in knowing how impactful an upgrade might be, and act accordingly.

@klehelley commented on GitHub (Nov 15, 2018): In a way, with Infrastructure as Code I would consider the resulting infrastructure to be the final "artifact" that external agents (API clients, etc. -- basically all the end-users of the features provided by the infrastructure being described) must interact with. With that point of view, knowing which version number to bump in not too hard to determine: * The change is strictly internal to the infrastructure being modified, with no impact visible by the external agents => patch * New features are added, but existing external agents can continue to use the deployed infrastructure as if the change never happened => minor * Features have been modified in a way that would break existing external agents, or removed => major Do note that in thinking this way, what I call external agents are not necessarily the ones concerned by the version you will provide (they may however be interested by the version of the endpoints they use, but that should be managed separately provided the infrastructure includes several independent endpoints). It is the person in charge of applying the Terraform plan to a given environment (and may have to intervene were any issue to happen within it) that will be interested in knowing how impactful an upgrade might be, and act accordingly.

GiteaMirror commented

2026-04-16 10:32:22 -05:00

@jwdonahue commented on GitHub (Nov 25, 2018):

@jruts, unless you have further questions or comments, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Nov 25, 2018): @jruts, unless you have further questions or comments, please close this issue at your earliest possible convenience.

GiteaMirror commented

2026-04-16 10:32:23 -05:00

@jruts commented on GitHub (Nov 26, 2018):

Thanks for the reply!

@jruts commented on GitHub (Nov 26, 2018): Thanks for the reply!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1216