Moonchild wrote:Yes, it will be fixed with the point release.
And it's indeed something to keep in mind, but there is very little I can do about it unless I remove the hyphen from version indicators, which I'd rather not do. 19.0.x64 looks ugly and is incorrect (it's not a point version following 19.0).
You changed the version number in the first place, which is a bad idea. Just leave it be
Let me repeat the important point: There is no need or merit in patching the version number. There are only downsides.
What is wrong with "19.0" instead of "19.0-x64" or "19.0.x64"?
BTW: One of these downsides:
Code: Select all
246 <pluginItem blockID="p176">
247 - <match name="filename" exp="(NPSWF32\.dll)|(Flash\ Player\.plugin)" /> <versionRange minVersion="10.3" maxVersion="10.3.183.18.999" severity="0" vulnerabilitystatus="1">
248 + <match name="filename" exp="(NPSWF32\.dll)|(Flash\ Player\.plugin)" /> <versionRange minVersion="0" maxVersion="10.3.183.18.999" severity="0" vulnerabilitystatus="1">
249 <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
250 - <versionRange minVersion="20.0a1" maxVersion="*" />
251 + <versionRange minVersion="19.0a1" maxVersion="*" />
252 </targetApplication>
253 </versionRange>
254 </pluginItem>
Yeah, block that in 19.0a1 and later already... But not in PM x64 as 19.0-x64 < 19.0a1
Moonchild wrote:
nmaier wrote:"19.0-x64" < "19.0b" < "19.0" < "19.0.1-x64" < "19.0.1"
Yes, this looks about right for the logic in place, although I'm not sure how a/b is handled. Not my favorite choice, they'd have been better off doing a string comparison instead of mathematical one...
There is no special handling for a/b. The algo is like this:
Blocks are delimited by a ".".
Parse each block into:
<number-a><string-b><number-c><string-d> (<string-rest>)
numbers will default to 0. strings will default to "".
numbers are compared numerically, strings using strcmp basically.
"0", "" -> (0, "", 0, "")
"19" -> (19, "", 0, "")
"19.0a1" -> (19, "", 0, ""), (0, "a", 1, "")
"19.0-x64 -> (19, "", 0, ""), (0, "-x", 64, "")
When comparing two versions, and one version has more blocks than the other one, fill the other one with blocks (0, "", 0, "")
Pseudo cmp algo:
Code: Select all
for each block:
if v1.numA < v2.numA:
return -1
if v1.numA > v2.numA:
return 1
if strcmp(v1.strB, v2.strB) < 0:
return -1
if strcmp(v1.strB, v2.strB) < 0:
return -1
... numC ... strD
return 0
So there is actually a lot of strcmp going on
And here is the reason plain string comparison is a bad idea:
Code: Select all
#include <stdlib.h>
#include <stdio.h>
#include <memory.h>
const char* vec[] = {
"", "a", "a", "", "a", "a", "a", "b", "b", "a", "1", "19", "19", "1", "9", "19", "19", "9", 0
};
int main() {
for (const char **v = vec; *v; v += 2) {
int rv = strcmp(*v, *(v+1));
const char* rs = rv < 0 ? "first" : (rv > 0 ? "second" : "same");
printf("[%s] [%s] smaller: %s\n", *v, *(v+1), rs);
}
return 0;
}
$ cc -o test test.c && ./test
[] [a] smaller: first
[a] [] smaller: second
[a] [a] smaller: same
[a] [b] smaller: first
[b] [a] smaller: second
[1] [19] smaller: first
[19] [1] smaller: second
[9] [19] smaller: second
[19] [9] smaller: first
Look at the last two lines: oops
Moonchild wrote:
EDIT: Unfortunately, in case you wonder why this is difficult: changing version numbers for specific parts will break things internally. It's the way the Mozilla code base is programmed, the version information has to match exactly between different components.
"Maintenance hell" is nothing compared to having to hunt down all locations in the entire source tree and make specific amends for the locations where the version string of the application matters. For example, If the version string is changed you have to completely clobber the build and rebuild it from scratch or you have a browser with many parts broken.
There are basically only four places where the version is defined:
- /xpcom/components/Module.h: mozilla::Module::kVersion is just the major version for binary compatiblity e.g. 19, but not 19.0.
- /browser/config/version.txt: This one you patches, leading to you also patching update URLs and stuff as yet another downside.
- /config/milestone.txt, /js/src/config/milestone.txt: Gecko, JS engine milestones (versions)
There simply is no need to "hunt down all locations in the entire source tree" as there is only a single location you patched in the first place.
Any other "hunting" is a result of the ill-advised version patching.
Moonchild wrote:
@nmaier: Just a quick question, would using an appinfo.version of "19.0.0-x64" have avoided this problem? Because that would be easy enough to do next time there is a new major release.
Just try it out
I gave you a code snippet:
Code: Select all
Components.utils.import("resource://gre/modules/Services.jsm", {}).Services.vc.compare("19.0-x64" /* pm */, "19.0" /* minVersion */)
Run that in a chrome-enabled Web Console or Scratchpad. To enable chrome open e.g. about:config or about:memory
Still changing the version string is a bad idea in the first place!