Library Host Dependency #172

New Issue

GiteaMirror · 2026-02-17T11:30:00-06:00

GiteaMirror commented

2026-02-17 11:30:00 -06:00

Originally created by @Coding-Badly on GitHub (Mar 16, 2015).

Semantic Versioning works well for things that depend on the whatever-is-being developed. Your Firetruck / Ladder example illustrates this idea well.

However, there is a need to indicate dependencies in the other direction. For example, I have written a few libraries for Arduino. Some only function correctly with Arduino IDE 1.0, some only function correctly with Arduino IDE 1.6, some work with both versions. Indicating this information in the version number be very helpful to the customer and would certainly eliminate some support.

Originally created by @Coding-Badly on GitHub (Mar 16, 2015). Semantic Versioning works well for things that depend on the whatever-is-being developed. Your Firetruck / Ladder example illustrates this idea well. However, there is a need to indicate dependencies in the other direction. For example, I have written a few libraries for Arduino. Some only function correctly with Arduino IDE 1.0, some only function correctly with Arduino IDE 1.6, some work with both versions. Indicating this information in the version number be very helpful to the customer and would certainly eliminate some support.

GiteaMirror added the question label 2026-02-17 11:30:00 -06:00

GiteaMirror closed this issue

2026-02-17 11:30:01 -06:00

GiteaMirror commented

2026-02-17 11:30:02 -06:00

@bperrybap commented on GitHub (Apr 7, 2015):

The Arduino IDE releases are so far off from using a traditional development process and maj.min.pt release system that I don't believe anything like semver can be used to straighten out library IDE version dependencies.

In the bigger picture, it seems very odd to me to encode any sort of external dependencies into a version number at all. How could you ever keep up? and then the library revision number would have to be constantly change depending on the whims of the Arduino developers since they can change things or make new releases at any time.
And then how do you indicate holes for the releases that are not supported at all?
And then libraries can also depend on other libraries.
Seems like a real mess to try to encode all the dependency information into the library semver version number.

To me this is much more of a problem with Arduino itself than any sort of dependency need.
The Arduino team has been notorious for breaking things, since until very recently they didn't put much thought into backward compatibility or the complications created for 3rd party developers.
These are the guys that decided that it was a good idea to break 100% of the 3rd party library code between the final 1.0 release candidate and the actual 1.0 release with no alpha, or beta releases in between.

And then 1.5 started with many backward compatibility issues from 1.0 (at least for libraries)
Things have been tossed in or removed from releases with only a point bump on the revision number (not a minor or major bump) that have affect backward compatibility like changes to the gcc toolset - which broke much of the existing AVR progmem code.

To me the Arduino library dependency needs are well outside the scope of semver since the Arduino IDE is not using nor has ever used anything close to a traditional s/w versioning system much less a semver compliant versioning scheme.

I think this sort of backward / higher level type of dependencies would be better handled by the IDE itself by using the Arduino library.properties file where it would be possible to explicitly specify not only which IDE versions or ranges of IDE versions are supported, but also which other libraries and versions of those libraries are needed as well.

For now about the only thing that can be done is to put conditionals inside the actual library code that check for the ARDUINO value and then creator the compile with a decent error message.

@bperrybap commented on GitHub (Apr 7, 2015): The Arduino IDE releases are so far off from using a traditional development process and maj.min.pt release system that I don't believe anything like semver can be used to straighten out library IDE version dependencies. In the bigger picture, it seems very odd to me to encode any sort of external dependencies into a version number at all. How could you ever keep up? and then the library revision number would have to be constantly change depending on the whims of the Arduino developers since they can change things or make new releases at any time. And then how do you indicate holes for the releases that are not supported at all? And then libraries can also depend on other libraries. Seems like a real mess to try to encode all the dependency information into the library semver version number. To me this is much more of a problem with Arduino itself than any sort of dependency need. The Arduino team has been notorious for breaking things, since until very recently they didn't put much thought into backward compatibility or the complications created for 3rd party developers. These are the guys that decided that it was a good idea to break 100% of the 3rd party library code between the final 1.0 release candidate and the actual 1.0 release with no alpha, or beta releases in between. And then 1.5 started with many backward compatibility issues from 1.0 (at least for libraries) Things have been tossed in or removed from releases with only a point bump on the revision number (not a minor or major bump) that have affect backward compatibility like changes to the gcc toolset - which broke much of the existing AVR progmem code. To me the Arduino library dependency needs are well outside the scope of semver since the Arduino IDE is not using nor has ever used anything close to a traditional s/w versioning system much less a semver compliant versioning scheme. I think this sort of backward / higher level type of dependencies would be better handled by the IDE itself by using the Arduino library.properties file where it would be possible to explicitly specify not only which IDE versions or ranges of IDE versions are supported, but also which other libraries and versions of those libraries are needed as well. For now about the only thing that can be done is to put conditionals inside the actual library code that check for the ARDUINO value and then creator the compile with a decent error message.

GiteaMirror commented

2026-02-17 11:30:03 -06:00

@jwdonahue commented on GitHub (Dec 8, 2017):

@Coding-Badly, the dependency graph between packages/modules is a hard problem and probably provably NP. SemVer was not created to solve that problem. It is a good starting point for how to label the nodes in the graph, but not how to label the edges or sub-trees.

Unless you have further questions, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 8, 2017): @Coding-Badly, the dependency graph between packages/modules is a hard problem and probably provably NP. SemVer was not created to solve that problem. It is a good starting point for how to label the nodes in the graph, but not how to label the edges or sub-trees. Unless you have further questions, please close this issue at your earliest possible convenience.

GiteaMirror commented

2026-02-17 11:30:04 -06:00

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

Closed as resolved, thanks everyone for contribution 👍
@Coding-Badly 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: @Coding-Badly If you still have any questions, feel free to re-open