Closed Bug 943575 Opened 11 years ago Closed 10 years ago

Consider versioning the Mn client according to the gecko version it's bundled with

Categories

(Remote Protocol :: Marionette, defect)

Product:
Remote Protocol
Component:
Marionette
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jgriffin, Unassigned)

Details

Travis CI jobs for mozilla-b2g26 are currently using 'setup.py develop' to install the Marionette client, which pulls in the latest and greatest. This version isn't always entirely compatible with mozilla-b2g26. This problem will become more acute in the future when we start tinkering with the Marionette protocol in order to improve WebDriver compatibility. To address this, we might consider versioning the Mn client according to the version of gecko it comes from, so 26.x.y for the one that comes in mozilla-b2g26, 28.x.y for the version currently in m-c, etc. Gaiatest could be pinned to an appropriate range, e.g., marionette_client>=26.0,<27.0
I am in favour of adding useful meaning to our mostly random version numbers.
This sounds good to me, however I understand that Travis-CI is currently installing the latest version from PyPI and not the latest in-tree version, so I believe we would need to release the client from the various branches in order for this to work as described. Is is possible to have multiple 'active' versions available in PyPI?
(In reply to Dave Hunt (:davehunt) from comment #2) > Is is possible to have multiple 'active' versions available in PyPI? All versions are available from PyPI and can be downloaded as pip install SomePackage==version Since this is mainly to support whats done on travis maybe we can updating their .travis.yml and be explicit with what version it needs. Then add a step as part of their branching to bump the version in the .travis.yml (as well as making sure that we have bumped the version and released it)
As far as I'm aware only one version can be the active one in PyPI, so my question was more about how we can control what is installed when a user does not specify a version number. This could also become relevant to users of Marionette for released Firefox desktop builds. Should we default to the latest point version of the release, or of nightly?
Whats the common case? lets solve for that and for everyone else they will need to specify a version.
This isn't that different from packages which have different versions to support Python 2.x vs 3.x, like python-dateutil. In that case, you get the Python-3.x package with 'pip install python-dateutil', you have to know that you want 'pip install python-dateutil==1.5' if you're using Python 2.x. As far as what to default to, I don't think there's any great answer. Many people won't necessarily want the latest release version as soon as that release is made, so I think defaulting to the latest nightly and training people who want differently to use specific versions is probably the best thing to do. We might consider doing a version check between client and server so that the client will abort with an error if it's used with an incompatible server version.
If it helps, after Bug 943008 lands, Travis CI can do something like pip install -r travis_requirements.txt /path/to/gaia-ui-tests travis_requirements.txt will have the desired marionette_client package in it, so you can tailor what jobs will use what marionette_client by pointing to different requirements.txt files.
As far as I know this is done, do you agree/disagree ?
Flags: needinfo?(dave.hunt)
Yeah, although we decided to release branched packages as needed. For example we have: https://pypi.python.org/pypi/marionette_client-mozilla-b2g28_v1_3 https://pypi.python.org/pypi/marionette_client-mozilla-b2g30_v1_4 https://pypi.python.org/pypi/marionette_client-mozilla-b2g32_v2_0
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(dave.hunt)
Resolution: --- → FIXED
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.