mirror of
https://github.com/semver/semver.git
synced 2026-03-22 14:10:15 -05:00
Standard format for common information about software versions? #116
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#116
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @taladar on GitHub (Jan 27, 2014).
In the Haskell community in particular there have been many discussions in recent months about meta information one might attach to a software version either at or after release time.
I am talking of information like "is known to work with dependency x version y", "is known not to work with dependency x compile time option y", "is known not to work with dependency x versions less than version y",... which often come up in version constraints and are undecidable at release time for future versions of dependencies and hard to decide for any and all combinations of dependency versions, platforms, dependency compile time options, package compile time options,... if the author does not have a whole build farm at their disposal.
It might be useful to define a standard format for these kinds of information that is machine readable and could be used by build tools to decide which version of a package to use e.g. as a dependency.
Other information that might be useful in this context is "has known bug X" or "has known security hole X" where X might be simply a URL to a bug tracker or CVE or something similar specific to the project.
It might even be something to consider as an alternative to pre-release version numbers, just annotate the version with their known bugs and security holes from the start. That way would have the advantage that even release versions with large numbers of bugs would be avoided in the same way once the bugs are discovered and added to the annotation.
@jwdonahue commented on GitHub (Dec 5, 2017):
@taladar, I like the idea, see my response to #171. As I stated there, I don't think SemVer should expand its scope to deal with those issues. I believe it should be a separate, stand-alone standard that can be applied to other versioning schemes as well.
Unless you intend to pursue this further, please close this issue at your earliest possible convenience.