data (positive and negative numbers for all of the fields).
This has been fixed in more recent versions including 1.0.2. Because they have bad version values, we need to protect against that, e.g. the version numbers are commonly in the billions. So restrict the versions accepted to be >0 and <100
sbt test, loaded libmesos with a bad version and verified we don't proceed.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Build is green https://jenkins.mesosphere.com/service/jenkins/job/public-test-marathon-phabricator/577/ for more details.
| src/main/scala/mesosphere/mesos/LibMesos.scala | ||
|---|---|---|
| 29 | is there some special meaning to v0.0.0? If so, should it be a constant defined with a meaningful name? If not, then what's the difference between reporting v0.0.0 and v10000000.v100000000000.v1000000000? | |
| src/main/scala/mesosphere/mesos/LibMesos.scala | ||
|---|---|---|
| 29 | ugh. you get the point (ignoring the extra vs that made their way into my bogus example) | |
Its less than 1.1.0. 10000 > 1.1.0, so we would accept things.
| src/main/scala/mesosphere/mesos/LibMesos.scala | ||
|---|---|---|
| 29 | Its less than 1.1.0. The bug here is that mesos has a bug where it feeds garbage 64bit ints and we get versions like -41012481231.1240141401.1241014810 and 1231232013181.1031241041.142014101 | |
is there some special meaning to v0.0.0? If so, should it be a constant defined with a meaningful name? If not, then what's the difference between reporting v0.0.0 and v10000000.v100000000000.v1000000000?