compare txs versions

[octaeder]

I want to show that data currently stored in a version object is not sufficient for ordering them. For example, I compare official version 4.3.0beta1 and versions derived from git versions 4.3.0beta1-n-xxxxxxx from my own builds, where n is the number of commits to the master after the latest commit for beta1.

If I would build my version from the same last commit after release of 4.3.0beta1 then the git version would be 4.3.0beta1-0-xxxxxxx. Method Version::current() in UtilsVersion.cpp would extract git revision 0 from -0- in the git version, hence the version is 4.3.0beta0. Even so (current is 4.3.0beta0)

latestDevVersion > currentVersion  (i.e. 4.3.0beta1 > 4.3.0beta0)

is not true (as expected) because of the following code (since not both revisions are positive, the result is false):

bool revisionLarger = (revision > 0 && other.revision > 0 && revision > other.revision);

But assume your own build to be one commit after release of 4.3.0beta2 then condition would be 4.3.0beta2 > 4.3.0beta1. We expect order to be false, but from the code it is true. No logic expression can resolve the problem, because it doesn't know if the 1 in beta1 is the revision or the git revision. In fact we do not know at all if git version was 4.3.0beta1-1 or 4.3.0beta2-1.

If I'm right, then we would have to store n in a version object, and both type and revision. So we would have unified versions 4.3.0beta1-0 for the official version, and 4.3.0beta1-0 or 4.3.0beta1-1 or 4.3.0beta2-1 (s. examples) from the own builds (of which first one is identical to official one).

What do you think?

[sunderme]

well, in case of alpha/beta/rc , revision of current version should be the number after the text "alpha", etc.

[octaeder]

yes, that's clear. The problem arises, when current version is a build aside official versions (alpha, beta, rc, or stabel), i.e. commit number is greater than 0. In this case parsing TEXSTUDIO_GIT_REVISION in gitRevisionToInt gives a number which is used as revision of the version.

Ex. 1: Let TEXSTUDIO_GIT_REVISION be "4.3.0beta1-24-g5c925a387". Then the following statement in Version::current

v.revision = gitRevisionToInt(QString(TEXSTUDIO_GIT_REVISION));

sets revision of version to 24 (as if it where 4.3.0beta24).

Ex. 2: Let TEXSTUDIO_GIT_REVISION be "4.3.0beta2-1-g5c925a387", a build of master one commit after beta2. Then revision would be 1, so the version is 4.3.0beta1. This makes clearly problems when comparing versions.

So my conclusion is, that version object has to be enhanced to hold what I call commitsAfter. Versions from the examles then would be (in string form) 4.3.0beta1-24 and 4.3.0beta2-1 (the part after - being the value commitsAfter.

Meanwhile I changed the version object and enhanced Version::current.

[sunderme]

there is actually no reason to check the commits after. If there are no tags with a higher number, your version is at least up-to-date, so no info for the user needed.
(And if you are checking out git, the whole update checker is kind of redundant)

[octaeder]

Of course the problem will rarely be recognized. We can see this live with the real bug that alpha1 doesn't find beta1 - no hints came from anyone but me (tested with 4.3.0alpha1 portable). Be aware that previous example 2 shows that the updater would display incorrectly a new beta2, even so the build is based on a commit after beta2, so update check is not totally redundant. This could be irritating or misleading. The display of 4.2.3rc1 looks not so smart. If update level is set to Development Versions then update check shows:

(0) in first row is not the revision which is 1 (rc1). Looks like stable is running. If update level is set to stable then update check shows:

In fact we should remove gitRevisionToInt and assign correct current revision to v.revision. But this is not the best solution in all cases. This is what my version shows:

The names are consistent with what you see on the git release page. Information is complete since it shows (yellow mark) commits after in almost the same way as About dialog does. This will not be present if you use versions from the release page (no -0).

I hope you will merge my changes when everything is fine, because I will continue working on fixing the automated test.