Toxcore versioning scheme

[GrayHatter]

Suggestion

Operating under the assumption that toxcore will follow Semantic Versioning. I suggest we take on the uTox style of sem-ver.

There will be two version "tracks" available. The first will exist ~only in code, and will won't be exposed to git. The second will be publicly release, tagged in git, and serve as "supported" versions.

This scheme allows for rapid development outside of a specific version, and when trouble shooting bugs or issues, quick identification of where and what could have caused the bug.

The actual flow and tags I suggest follow. (And will be updated from accepted comments made in this thread)

Example:

git tag v0.0.0 e6af3a7825e8307a501bc7c3e7b1ff323f081870

Changes are made to the toxcore api (already done), version identified in code should be v0.1.0 but this version will not be exposed to (tagged in) git.

Following the completion of the ToxAV stateless update. The version in code will be v0.2.0, with the addition of git tag v0.2.0 (this commit may be optionally pushed to a new branch stable)

The very next commit to master will change the version to v0.2.1 and any/all commits will be merged into this branch.**

Once a new version is ready to be pushed to stable, the version in code will be incremented to v0.2.2 (optionally v0.3.0) with git tag v0.2.2. This branch will be pushed to stable.**

The very next commit to master will be v0.2.3 and there will be no git tag for this version.

Discussion

In as instant developers can know if a bug exists in a stable version, or only in the development branch, or again, if it has been fixed already in a development branch.

It allows (forces) package maintainers to use only stable versions if they wish when they package and release a version, (because only stable versions will get tagged.) The one caveat to this is packages may be versioned in inconstantly with the version reported by toxcore if packagers blindly use the version reported by git tag.

Finally, developers can enable debug mode by default, if they detect that they are using a development build of toxcore. (toxcore_version_patch() % 2)

[GrayHatter]

@iphydf @nurupo @JFreegman @mannol @tux3 @zetok @Chuongv

[zetok]

I suggest we take on the uTox style of sem-ver.

No, please don't introduce crap and use semver. There are no styles.

v0.0.1 – no stable API, anything beside API can break at any moment
v0.1.0 – you have a ~stable API
v0.1.1 – API is not broken, some fixes/improvements/internal changes
v0.2.0 – breakage in API, other changes

It's that simple. No insane 2-version jumps.

There's no point in discussing this. Use standards. And no, your whole idea about packaging is plain wrong – you're not making things easier, but harder by reinventing a square wheel.

What you seem to want to do, is following example of GTK/gnome regarding versioning – something that is widely agreed on as retarded in packaging world. You might want to ponder on that.

You might want to learn what semver is, since the versioning scheme proposed by you is not semver.

If you don't release something as tag in git, it doesn't get packaged. Period.
If it gets tagged, it is a release and gets packaged.

---

On a side note; you don't need a stable branch – use git tags.

[SkyzohKey]

Just to correct what @zetok said:

• 0.0.0 – Initial commit/not stable API ;
• 0.1.0 – API is still not stable but a new feature has been added ;
• 0.1.1 – Still not stable but patches a bug/issue/security flaw ;
• 0.2.0 – New feature gets added and released ;
• 1.0.0 – Stable API.

That's how semver is supposed to works, RELEASE.FEATURE.PATCH.