Reputation: 170
Versions in the dependency graph in modules and the actual modules in the pack in Ballerina
What are the scenarios can a version of a dependency of module foo (let's say bar) differs from the version packed in the pack?
Let's take crypto module. It is a dependency of module auth. When we check the 2201.8.6-swan-lake pack, we can see that, in the dependency-graph.json of auth, it says 2.5.0 as the version of the crypto. But, once we search for the crypto module packed with the pack is actually 2.6.2.
Upvotes: 1
Views: 61
Answers (1)
Reputation: 1610
The answer is simple: we package the latest compatible versions of ballerina/* packages when we release Ballerina platform distribution, such as Swan Lake Update 8.6.
ballerina/auth:2.5.0 - Released 10 months ago
ballerina/crypto:2.6.2 - Released 7 months ago.
Ballerina Swan Lake Update 8.6 - Released 3 months ago.
This strategy makes sense because that's exactly how the Ballerina Dependency resolver works. Do you see any issues with this approach?
Upvotes: 0
Related Questions
- The assertExactEquals is not working as expected for errors Ballerina testing
- VS Code does not resolve Ballerina modules and gives syntax errors
- What is the best practice for sharing records among modules in Ballerina?
- How to connect to the Gmail API in Ballerina?
- Are string numeric literals with floating point suffix the valid CLI arguments in Ballerina?
- Facing compilation error while trying to import the package in Ballerina
- Ballerina dependencies are resolved for the latest available than what specified in Ballerina.toml
- What is the difference between "anydata" and "any" types in Ballerina?
- How to use the `map` function with a ballerina stream?
- How to create empty table in Ballerina and to add the records gradually