Dependency is considered “open” if you don’t fix it to a particular version. In practice, it means that the next time you “build” software the most recent version of the dependency will be used.
# that's closed (fixed) dependency
requests=1.3.4
# that's open dependencies
requests
requests=any
# that's open dependency with lower bound.
requests=1+
# that's hybrid dependency
requests=1.3.*
It is usually considered a bad practice to use open dependencies. It is usually OK to use fixed dependency and it might be OK to use hybrid one. Before I explain why let’s consider the most common versioning system.
There’re many conventions for versioning software, but one is used most often. Arguably the only right one. Let’s consider it:
{majour version}.{minor version}.{hotfix/patch}
The last part is optional. For example:
version = 1.3.4
# or
version 1.3
Using this convention is very handy for libraries. And here’s why.
All potentially breaking updates are considered major. When you change the first number of the version you’re essentially saying to library users: “it’s likely you will need to update your code to be able to use this library”.
That’s probably one of the reasons why the Java version was 1.6-1.8 before they changed the versioning logic.
Minor version updates are supposed to be backwards compatible. I.e. while it’s perfectly OK to add new features and fix bugs in minor version updates, all the previous functionality is supposed to be working as it did before.
Think of Java versions again.
If there’s no patch - there may be no patch update version (or it may be “0” - like 1.3.0). These are often used for minor bug fixes. Must be safe to update.
Simple - it is risky. There are three main risks: