[GH-ISSUE #428] Event based versioning #1181

New Issue

GiteaMirror · 2026-04-16T10:29:44-05:00

GiteaMirror commented

2026-04-16 10:29:44 -05:00

Originally created by @elypter on GitHub (Feb 7, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/428

This is an outline for a mechanism that goes beyond classic versioning and is not meant to compete with semver or other versioning systems. instead of condensing all compatibility information in a set of numbers it intends to store the information about compatibility in its raw form like it comes from the developer and like it is most useful for applications as well. it should work as follows:

every commit specifies of what type the change is, the commit comment, when it happened and what version it is called.
the commit history is either distributed as a file or made available on a remote location so it can be read with tools (eg: a git repository)
instead of standardizing the version number the types of commits are being standardized.
if an application wants to find out if a dependency version is compatible it can check if there has been a commit between the one it has been originally built for that is of the type major and then decide to upgrade to the last commit before it. this would be the classic approach.
an application can do more complicated checks too like check if the dependency of a dependency is within certain limits by checking for events which may look like event:dependencyupgrade(libxyz, 1.2.3, 1.2.5) and upgrade only until before libxyz jumps to 2.0.0
you can search for the newest version that uses the file format version 3.x
events can also mark certain api compatibilities by giving them names when they are introduced and using the same name when compatibility is being removed. eg: event:addapi(commandline,locationxy), event:removeapi(commandline,locationxy) and event:changeapi(commandline,locationxy)
-this would also help with confusion between different branches if version numbers are not compatible because you can just look for events and it doesnt matter if the event happens in a nightly, a stable or a backport.
with this approach you can also create the semver string automatically and even create version strings for other versioning systems. it can also create versions for different apis and the build environment(plugin api version, fileformat version, commandline option version, ...)
you can even do improved version compatibility checks if you do not use a semver. just select the last version that is marked compatible and then flollow the commits until an event that is of the type major.
it can automatically skip versions that introduce regressions if the commit information includes information that an update broke something.
for projects that do not provide that information it could be added by others manually and even a comment history that is not complete can be useful.
it might be possible to create the events automatically with code inspection tools and to use heuristics on what files changed and the commit comment.

Originally created by @elypter on GitHub (Feb 7, 2018). Original GitHub issue: https://github.com/semver/semver/issues/428 This is an outline for a mechanism that goes beyond classic versioning and is not meant to compete with semver or other versioning systems. instead of condensing all compatibility information in a set of numbers it intends to store the information about compatibility in its raw form like it comes from the developer and like it is most useful for applications as well. it should work as follows: - every commit specifies of what type the change is, the commit comment, when it happened and what version it is called. - the commit history is either distributed as a file or made available on a remote location so it can be read with tools (eg: a git repository) - instead of standardizing the version number the types of commits are being standardized. - if an application wants to find out if a dependency version is compatible it can check if there has been a commit between the one it has been originally built for that is of the type major and then decide to upgrade to the last commit before it. this would be the classic approach. - an application can do more complicated checks too like check if the dependency of a dependency is within certain limits by checking for events which may look like event:dependencyupgrade(libxyz, 1.2.3, 1.2.5) and upgrade only until before libxyz jumps to 2.0.0 - you can search for the newest version that uses the file format version 3.x - events can also mark certain api compatibilities by giving them names when they are introduced and using the same name when compatibility is being removed. eg: event:addapi(commandline,locationxy), event:removeapi(commandline,locationxy) and event:changeapi(commandline,locationxy) -this would also help with confusion between different branches if version numbers are not compatible because you can just look for events and it doesnt matter if the event happens in a nightly, a stable or a backport. - with this approach you can also create the semver string automatically and even create version strings for other versioning systems. it can also create versions for different apis and the build environment(plugin api version, fileformat version, commandline option version, ...) - you can even do improved version compatibility checks if you do not use a semver. just select the last version that is marked compatible and then flollow the commits until an event that is of the type major. - it can automatically skip versions that introduce regressions if the commit information includes information that an update broke something. - for projects that do not provide that information it could be added by others manually and even a comment history that is not complete can be useful. - it might be possible to create the events automatically with code inspection tools and to use heuristics on what files changed and the commit comment.

GiteaMirror closed this issue

2026-04-16 10:29:45 -05:00

GiteaMirror commented

2026-04-16 10:29:46 -05:00

@jwdonahue commented on GitHub (Mar 24, 2018):

@elypter, This issue has nothing to do with SemVer and is unlikely to result in a PR. Please close at your earliest possible convenience.

@jwdonahue commented on GitHub (Mar 24, 2018): @elypter, This issue has nothing to do with SemVer and is unlikely to result in a PR. Please close at your earliest possible convenience.

GiteaMirror commented

2026-04-16 10:29:46 -05:00

@jwdonahue commented on GitHub (Aug 18, 2018):

@Haacked, time to close this one.

@jwdonahue commented on GitHub (Aug 18, 2018): @Haacked, time to close this one.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1181