Skip to content
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

Report via check when a project does not use semantic versioning #728

Open
benmss opened this issue May 2, 2024 · 3 comments
Open

Report via check when a project does not use semantic versioning #728

benmss opened this issue May 2, 2024 · 3 comments
Assignees

Comments

@benmss
Copy link
Member

benmss commented May 2, 2024

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.

@jenstroeger
Copy link
Contributor

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.

@behnazh-w
Copy link
Member

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?

@jenstroeger
Copy link
Contributor

jenstroeger commented May 13, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants