Versioning community edition
rugk opened this issue · 8 comments
What do you think: Howe should be versionize the community edition.
Currently I've written in the wiki that the version number should be separate from the official one, but I'm not sure whether this is the best way to go.
I just thought that versions like v1.1.2-community_v0.1 are a bit too long...
Anyone having any thoughts or suggestions?
Good question. Tag/version names should match 'X.Y.Z', or 'vX.Y.Z', with an optional suffix for RC, beta, alpha or patch versions. What do you say to a suffix for Community Edition?
=> v1.1.2-CE_v0.1 (but this is something I have not seen)
Here are a few sources:
Managing package versions - https://packagist.org/about
and
Semantic Versioning 2.0.0 - http://semver.org/
Regards
According to http://semver.org/ it is also possible for pre-release versions to use version slike 1.0.0-0.3.7, 1.0.0-x.7.z.92. At least the latest looks quite similar to our idea, but seriously I do not know what version is actually meant by "x.7.z.92".
Additionally a community edition is not really a "pre-release" version... 😒
Another problem is this:
Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-].
So in fact it is not possible to use _ there, which changes our result to "v1.1.2-CE0.1" or "v1.1.2-CE-0.1".
Okay, I've asked at the semver repo about this: semver/semver#278
Let's see if we get a solution for this problem which adheres to semantically versioning.
Good idea! I look forward to the answer. 👍
So finally there was a reply and a reference to two other issues which show that this is a quite common problem.
So what do you think?
Okay, so what about v1.1.3-CE.1 which mean first community edition version of original SDK v1.1.3?
I think for now we do not need more version numbers after the .. You cannot really make a difference between major and minor versions (which should be API-compatible) here as we anyway have to (and should be) compatible with the official version.
As we also publish this library on packagist we also have to pay attention to this. Especially because packagist normally recommend to use semantic version numbers...
As I don't know the consequences if we do not use a semantic version number I've asked on Stackoverflow: https://stackoverflow.com/questions/33946030/what-are-the-consequences-of-using-a-non-semantic-version-number-in-composer-for
Especially because of the version number issue I changed my approach: I will not publish a community version.
Instead of doing so I will send all patches/changes to Threema so that they can merge them into the official version. After this is done and the official version is released I'll also release it here.
The most up-to-date version with all changes can always be found in "master" and this is also the branch. So I am closing this issue.
the next release will be just the version number...