-
Notifications
You must be signed in to change notification settings - Fork 8
Package dependency guidelines #558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
TODOs:
|
I cannot recall what we decided here in the end. If we are only releasing by tagging main as we go then this makes sense, if you have to update a version range to extend support to a new version with a fix this means a release so users can get a non-vulnerable version. If we have multiple release branches, does this mean we intend to keep dependencies for all of these up to date? Can we even do that with dependabot? |
I think it's only feasible to do this on the main branch. We did discuss that if the metapackage and / or downstream app developers cannot match non-vulnerable versions (using our release), they can provide another signal that a new release might be required. |
Coming from ansys/pyansys#842 (comment) we realized that this information is not published anywhere. We should clarify better how packages should handle dependencies for various purposes - just like @greschd outlined there.
The text was updated successfully, but these errors were encountered: