You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This may need further investigation before it can be addressed.
One benefit to having such a check would be allowing users to see when their project is relying on dependencies that do not communicate breaking changes in the semver way.
In cases where the commit finder is not invoked, this check would be limited to analysing the singular version of the artefact being examined. However, whether it actually makes sense to analyse the full list of tags from a repository is also open to debate as some repositories may have only used non-semver schemes at some point in the past, meaning their most recent versions (as tags) are fine.
The text was updated successfully, but these errors were encountered:
I think it’s important to consider a version number like 1.2.3 and a semantic version number 1.2.3. The difference? There is none.
Semantic versioning is about interpreting the version number, it’s not inherently built into it.
Case in point: up until v2 Pydantic did not use semantic versioning and v1.10.0 broke v1.9.x (Changelog). As of v2, those folks plan to be more diligent with their version numbers 🤞🏼 I’ve seen projects document in their Changelog that their version numbers follow semver (can’t find an example right now), but at least Python package metadata (docs) doesn’t seem to communicate how to interpret the version number (docs) wrt. semver.
If a Changelog is available for a release, we could also consider a lightweight text processing to detect breaking changes, features, and patches to see if the project has followed semantic versioning for a particular version. What do you think?
Also, I think it would make sense to bring this up with the Python discussion forum and suggest additional package metadata that identifies the version schema. Won’t solve your problem here right now, but… 🤷🏻♂️
Addendum: Take a look at SQLA’s interpretation of their version string here (section “Version Numbering Scheme”), to give an example of a popular package with a different version scheme.
This may need further investigation before it can be addressed.
One benefit to having such a check would be allowing users to see when their project is relying on dependencies that do not communicate breaking changes in the semver way.
In cases where the commit finder is not invoked, this check would be limited to analysing the singular version of the artefact being examined. However, whether it actually makes sense to analyse the full list of tags from a repository is also open to debate as some repositories may have only used non-semver schemes at some point in the past, meaning their most recent versions (as tags) are fine.
The text was updated successfully, but these errors were encountered: