Closed
Bug 1126446
Opened 11 years ago
Closed 11 years ago
balrog version comparison not working properly with versions like 38.0a1
Categories
(Release Engineering Graveyard :: Applications: Balrog (backend), defect)
Release Engineering Graveyard
Applications: Balrog (backend)
x86_64
Linux
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: bhearsum)
Details
Noticed this today while catlee was debugging a GMP rule:
>>> version_compare("38.0", ">=38.0")
True
>>> version_compare("38.0a1", ">=38.0")
False
Both of those should evaluate True.
Comment 1•11 years ago
|
||
a1 == alpha 1 == trunk (in present times)
a2 == alpha 2 == aurora (in present times)
38.0 == beta == release
a1 is certainly not == to release nor is it newer than release.
See https://developer.mozilla.org/en-US/docs/Toolkit_version_format for more information
Assignee | ||
Comment 2•11 years ago
|
||
This is actively screwing up serving correct EME blobs. Eg:
https://aus4.mozilla.org/update/3/GMP/38.0a1/20120222174716/WINNT_x86-msvc/en-US/nightlytest/default/default/default/update.xml
is getting version 4, but should be getting version 6.
(In reply to Justin Wood (:Callek) from comment #1)
> a1 == alpha 1 == trunk (in present times)
> a2 == alpha 2 == aurora (in present times)
> 38.0 == beta == release
>
> a1 is certainly not == to release nor is it newer than release.
I can see how this is confusing when read this way. I think our disconnect here stems from the fact that when I'm comparing 38.0a1 >= 38.0 in my head, what I'm really doing is asking whether or not 38.0a1 is on the same or a newer train than 38.0.
It's hard to decide what the ideal behaviour is here when we don't make use of tags like "a1" much anymore. Ignoring them certainly makes sense in the context of GMP where we think of things as Gecko-version centric. It's hard to consider the case where we actually care about how a1 or a2 may affect the comparison when those tags are static these days. Eg, we never ship a series of alphas from the same Gecko version.
However, the more I think about it the more that continuing to support them seems like the right thing to do. I think we can fix up EME by using versions like "38.0a1" rather than "38.0".
As a hypthetical, if we ever started shipping betas with "bN" in them again, preserving support for comparisons between versions like 38.0b5 and 38.0b6 would be very useful.
I'm going to get some test rules set-up to make sure this works before changing the live ones.
Assignee: nobody → bhearsum
Assignee | ||
Comment 3•11 years ago
|
||
Okay, after setting up a parallel set of rules with channel="gmptest" and adding "a1" to each version restriction, things appear to be working. While https://aus4.mozilla.org/update/3/GMP/38.0a1/20120222174716/WINNT_x86-msvc/en-US/nightlytest/default/default/default/update.xml is getting EME version 4, https://aus4.mozilla.org/update/3/GMP/38.0a1/20120222174716/WINNT_x86-msvc/en-US/gmptest/default/default/default/update.xml is correctly getting EME version 6.
I've gone ahead and made the version change to real GMP rules.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•