search

kroyee / SpeedBlocks

Fast paced tetris game cloned from Cultris II
GNU Lesser General Public License v3.0
11 stars 7 forks source link

[Discussion] Versioning schema #80

Closed Noir- closed 7 years ago

Noir- commented 7 years ago

I think this is also a thing which should be done before the first beta. I suggest semantic versioning. Summary:

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Even though this is no software library, we got a client-server model and there's already the idea of a client API. So we can't do anything wrong with that and it's pretty easy to follow. Thoughts?

kroyee commented 7 years ago

It's a good idea. So that means we start at 0.1.0 for the first beta release I guess? There is currently a version number in the client, that is checked with the server when you connect, but it does not follow this. Very easy to adjust though.

texus commented 7 years ago

Anothing important part to quote about semantic versioning the the following:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Basically the rules about major, minor and patch versions only apply once you reach version 1.0.0. And you shouldn't go to 1.0 too quickly because then you might end up rapidly incrementing the major version. Semantic versioning is needed when you have something stable, not during development.

But it is still a good idea to have small fixes and changes as an increment in the patch version and larger changes as an increment in the minor version.

Edit: I read a bit further and what I said was not entirely correct, for major version 0 you still have to follow the rules for minor and patch versions except for the backward compatibility stuff. But I think you will most likely end up only incrementing the minor version most of the time anyway, making a new release just for a minor internal fix is going to be rare. But my opinion is still: it doesn't matter much while in 0.x, just give it a version that makes sense.

Noir- commented 7 years ago

Yeah I also think that there is no need to apply it to strict at the moment. But we already can get used to the scheme and adjust tooling and stuff to it.