shiro Versioning Shiro: What and how

Versioning Shiro: What and how

Open mellowagain opened this issue 5 years ago • 3 comments

Shiro is nearing the completion of it's last major aspect. We should start versioning Shiro to keep track of updates easier and to allow the implementation of a changelog to be displayed on the frontend, Kuro.

There are multiple version schemes to choose from:

SemVer

Most widespread in software development, SemVer proposes the usage of incremental version parts. It is suggesting the usage of major.minor.fix layout. With a major breaking change, the major part of the version gets upgraded and symbolizes no backwards compatibility. The same applies to minor and fix but does not symbolize breaking backwards compatibility.

Resulting versions would look like this: v1.33.7

Date

Simple and straight forward date versioning. It displays the date of the release right in the version number. It suggests the layout of vyearmonthdate.fix. With each release, the date is updated to the day the new version gets released. If another update is released on the same day, the fix part gets incremented.

Resulting versions would look like this: v20181009.2

Build

Build numbers are straight forward incremental changes to the versioning system. Instead of having well defined parts that indicate something, the number just gets incremented every time a new update is released. It suggests the usage of buildnumber as single integer, without any other parts.

Resulting versions would look like this: b5427

Date & CI Build

A mix between Date and the continues integration build number. This versioning scheme is used by osu!lazer and newer, open-source ppy projects. In principle, it is the same as the Date versioning system but uses the CI build additionally instead of the month and day. It suggests the following layout: vyear.cibuild.fix

Resulting versions would look like this: v2018.205.3

Git Hash

Probably the most straight forward way to name a version. No thinking about if this is a minor or fix, no dates to organize or some other stuff - at the expense of being cryptic and ununderstandable to people who do not use Git as version control system.

Resulting versions would just be a git short commit hash and look like this: 22df1fe

Other

Got another suggestion or even a mix between two suggested (e.g v1.33.7-22df1fe), feel free to reply to discussion with it and it will be considered as well.

Discussion is open and I'm looking forward to input of any collaborator as well as other people.