clarifying "Stable packages depends on libraries that are at level X"
shiftkey opened this issue · comments
I think I understand the intent here but wanted to call out some interesting threads about this that I've spotted in the wild (going to paraphrase):
- The mention of
packageshere suggests this is about auditing NuGet releases - does this mean that projects that don't distribute on NuGet are not a good candidate currently for the maturity model? - Is there any flexibility here for projects that may depend on things which aren't distributed by NuGet but are needed for the project (e.g. web frameworks shipping JS that is sourced from a third-party)?
How set are we on this currently, and who are the best people to bug about exploring dependencies that aren't on NuGet?
Great question ... I had an earlier write-up that covered this, but I forgot about this topic and it didn't make the final doc. Here is my take:
- This isn't about NuGet, per se, but .NET code. NuGet is the dominant distribution model, so that explains the focus on NuGet.
- This model is NOT intended to cover dependencies from other ecosystems (JS, C++, ...). So, a .NET project can depend on Electron or Angular or TensorFlow, and it can be at any of the four maturity levels. A Level 4 library that has such a dependency is level 4 w/rt to .NET, and any confidence concerns for the users of the library w/rt Electron (for example) are left to the consumer to consider (and not the maturity ladder).
So, I should add some text on this scenario to the doc, but it will only clarify what I said above. The maturity ladder will not place any requirements on dependencies from other ecosystems. It's not really possible/tenable.
Make sense?
@richlander I think that answers the questions I had. Happy to review proposed changes to the doc if it'll help.