Noticed these today: ValueError: invalid version number '3.6.3plugin1' Stacktrace (most recent call last): File "flask/app.py", line 1060, in full_dispatch_request rv = self.dispatch_request() File "flask/app.py", line 1047, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "flask/views.py", line 56, in view return self.dispatch_request(*args, **kwargs) File "flask/views.py", line 112, in dispatch_request return meth(*args, **kwargs) File "auslib/web/views/client.py", line 35, in get release, update_type = AUS.evaluateRules(query) File "auslib/AUS.py", line 120, in evaluateRules queryVersion = StrictVersion(updateQuery['version']) File "distutils/version.py", line 40, in __init__ self.parse(vstring) File "distutils/version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring They were against dev, but it's pretty clear that this will be an issue for production too.
Created attachment 8410436 [details] [diff] [review] allow slightly looser versions This patch stems the bleeding by allowing more than "a" or "b" as a prerelease tag. I think it would be good to catch ValueErrors when we're parsing versions, but I'm not sure what to do in evaluateRules when we hit one. It almost seems like an invalid state for a blob to be in, so maybe it's ok to ignore for the releaseVersion parsing? For the incoming version, perhaps setting it to the lowest possible thing (0?) might be best? I'm curious about your thoughts on this.
Comment on attachment 8410436 [details] [diff] [review] allow slightly looser versions Seems fine to me.
Commit pushed to master at https://github.com/mozilla/balrog https://github.com/mozilla/balrog/commit/42386c785e7cecdc555704571fc693d1e25225d7 bug 999423: tracebacks on versions like 3.6.3plugin1. r=nthomas
In production, shouldn't be an issue anymore...