What about build/toolchain upgrades? #243

Closed
opened 2026-02-17 11:39:40 -06:00 by GiteaMirror · 3 comments
Owner

Originally created by @jdemeyer on GitHub (Oct 6, 2016).

Originally assigned to: @steveklabnik on GitHub.

Is a change to the build system of a project considered an API change for semver purposes?

In other words, suppose I have some project Foo-1.0.0 and I change its build system to require different build tools in a backwards-incompatible way (i.e. the old tool won't build the upgraded project or it requires an additional tool). Once the project is built, the API remains exactly the same as before. Am I then required to bump the version to 2.0.0 or could it be 1.1.0?

Originally created by @jdemeyer on GitHub (Oct 6, 2016). Originally assigned to: @steveklabnik on GitHub. Is a change to the build system of a project considered an API change for semver purposes? In other words, suppose I have some project `Foo-1.0.0` and I change its build system to require different build tools in a backwards-incompatible way (i.e. the old tool won't build the upgraded project or it requires an additional tool). Once the project is built, the API remains exactly the same as before. Am I then required to bump the version to `2.0.0` or could it be `1.1.0`?
GiteaMirror added the question label 2026-02-17 11:39:40 -06:00
Author
Owner

@arcticicestudio commented on GitHub (Oct 6, 2016):

I think there is no need to explicitly release a new version if only the build tool changed. You can merge it into your develop branch (if your're using gitflow) and release it in the next version which may contain features or improvements ( no patch version).
But if you'd like to release it nevertheless it should be 1.1.0 since this can be considered as a kind of improvement (or at least it should be or there's no reason to switch the build system 😄 ).

@arcticicestudio commented on GitHub (Oct 6, 2016): I think there is no need to explicitly release a new version if only the build tool changed. You can merge it into your `develop` branch (if your're using gitflow) and release it in the next version which may contain features or improvements ( no patch version). But if you'd like to release it nevertheless it should be `1.1.0` since this can be considered as a kind of improvement (or at least it should be or there's no reason to switch the build system :smile: ).
Author
Owner

@jwdonahue commented on GitHub (Nov 30, 2017):

@jdemeyer, this is yet another "what is being versioned?" question. Do you ship the build system, make files, IDE project files? If so, you've made a backwards incompatible change and should bump the major version number. If not, you're in the clear, even if you've got an open source project with thousands of developers sharing the same project/make files.

If this answers your question please close this issue at your earliest convenience.

@jwdonahue commented on GitHub (Nov 30, 2017): @jdemeyer, this is yet another "what is being versioned?" question. Do you ship the build system, make files, IDE project files? If so, you've made a backwards incompatible change and should bump the major version number. If not, you're in the clear, even if you've got an open source project with thousands of developers sharing the same project/make files. If this answers your question please close this issue at your earliest convenience.
Author
Owner

@alexandrtovmach commented on GitHub (Jun 10, 2020):

Closed as resolved, thanks everyone for contribution 👍
@jdemeyer If you still have any questions, feel free to re-open

@alexandrtovmach commented on GitHub (Jun 10, 2020): Closed as resolved, thanks everyone for contribution :+1: @jdemeyer If you still have any questions, feel free to re-open
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#243