Use semantic versioning? #465

New issue

Open

opened 2021-09-13 22:26:12 -06:00 by onlyjob · 4 comments

onlyjob commented

2021-09-13 22:26:12 -06:00

(Migrated from github.com)

So many numbers are in the release version... Let's consider using standard Semantic Versioning practice please: https://semver.org/

RElesgoe commented

2021-09-14 00:10:07 -06:00

(Migrated from github.com)

If I recall correctly, the original PvPGN developers wanted PvPGN 2.0 to become a general server software for all kinds of games, so they versioned their ongoing rewrite as 1.99.0/1.99.rXXX. This goal was never achieved and the repository was eventually forked, resulting in this one.

As you can see now, the 1.99.X part of the version number was carried over from the parent repository and has evolved into 1.99.X.X.X.

Why? Because updating the major version to 2 without implementing the aforementioned goal would go against the original developers' wishes. We could make the version number more pretty by slightly deviating from the Semantic Versioning specification by forever updating just the minor and patch versions (e.g. 1.103.4), but that wouldn't communicate anything Semantic Versioning wants to communicate.

As a compromise, the last 3 parts of the version number follows Semantic Versioning, leaving the 1.99 indefinitely frozen.

If I recall correctly, the original PvPGN developers wanted PvPGN 2.0 to become a general server software for all kinds of games, so they versioned their ongoing rewrite as `1.99.0`/`1.99.rXXX`. This goal was never achieved and the repository was eventually forked, resulting in this one. As you can see now, the `1.99.X` part of the version number was carried over from the parent repository and has evolved into `1.99.X.X.X`. Why? Because updating the major version to 2 without implementing the aforementioned goal would go against the original developers' wishes. We could make the version number more pretty by slightly deviating from the Semantic Versioning specification by forever updating just the minor and patch versions (e.g. `1.103.4`), but that wouldn't communicate anything Semantic Versioning wants to communicate. As a compromise, the last 3 parts of the version number follows Semantic Versioning, leaving the `1.99` indefinitely frozen.

onlyjob commented

2021-09-14 02:10:24 -06:00

(Migrated from github.com)

Thanks for explanation and for considering. Current versioning is weird and unusual with too many meaningless version numbers. If intention was to just keep 1.99 and append semantic version to it, then it defeats the best practice and deviates much further from (traditional) 1.103.4 example.

IMHO next release should be 1.100.1 or 1.99.8. Everything after third number in version is confusing and carries no useful meaning. And certainly current versioning pattern fails to communicate anything meaningful.

Can we keep this issue open please, for more discussion?

Thanks for explanation and for considering. Current versioning is weird and unusual with too many meaningless version numbers. If intention was to just keep `1.99` and append semantic version to it, then it defeats the best practice and deviates much further from (traditional) `1.103.4` example. IMHO next release should be `1.100.1` or `1.99.8`. Everything after third number in version is confusing and carries no useful meaning. And certainly current versioning pattern fails to communicate anything meaningful. Can we keep this issue open please, for more discussion?

RElesgoe commented

2021-09-16 19:56:42 -06:00

(Migrated from github.com)

You're saying appending a semantic version to 1.99 defeats the best practice but the best practice needs to utilize all 3 version parts (major, minor, patch). Your suggestion to only update the minor and patch version also goes against best practice.

After you understand which parts of the current versioning scheme to look at (and which parts to ignore), it's all fine because the only relevant components are the components of semantic version.

You're saying appending a semantic version to `1.99` defeats the best practice but the best practice needs to utilize all 3 version parts (major, minor, patch). Your suggestion to only update the minor and patch version also goes against best practice. After you understand which parts of the current versioning scheme to look at (and which parts to ignore), it's all fine because the only relevant components are the components of semantic version.

cen1 commented

2021-09-17 13:51:18 -06:00

(Migrated from github.com)

Current repo has deviated from 1.99 quite a bit and 2.0 as originally envisioned will never be achieved so perhaps in the spirit of keeping the legacy idea alive, how about skip straight to 3.0?

Not that it really matters because there is not enough contributions to even do releases nowadays but for the sake of keeping things in order, maybe.

Current repo has deviated from 1.99 quite a bit and 2.0 as originally envisioned will never be achieved so perhaps in the spirit of keeping the legacy idea alive, how about skip straight to 3.0? Not that it really matters because there is not enough contributions to even do releases nowadays but for the sake of keeping things in order, maybe.