The currently released version of mozdevice is 3.2.3.

As part of bug 1486004, I am intending to release an incompatible version of mozdevice which handles rooted devices in an incompatible way to the previous versions of mozdevice and intend to bump the version to 4.0.0 to reflect that incompatibility.

The current requirements specifying mozdevice in the tree all use the minimum syntax which means as soon as 4.0.0 is released, it will begin to be used. This is a minor temporary problem on trunk but we also use mozdevice with android hardware on mozilla-beta, mozilla-release, mozilla-esr68 and now mozilla-esr78 which would immediately break when mozdevice 4.0.0 is released since they would attempt to use it even though the current testing code in those branches would not support it.

I think I need to change the current mozdevice requirements in tree to state >= 3.2.3,<4.0 and land this on trunk, then uplift this to mozilla-beta, mozilla-release, mozilla-esr68 and mozilla-esr78 before I can land the new mozdevice 4.0.0.

ahal, wlach: Does this sound alright to you?

I've NI ahal and wlach directly but would appreciate any suggestions anyone else might have as well.

This patch applies to trunk and beta. A different version applies to release and mozilla-esr78 while a third version applies to mozilla-esr68. I'm not clear on the process for uplifting these once this lands on mozilla-central. Do I use phabricator?

For in-tree stuff those version specifiers aren't used anyway (we just use whatever copy exists in-tree). So this will only affect out-of-tree consumers like mozregression.

I agree that we should ensure we don't automatically upgrade to the next major version (maybe we should do this for all those packages while we're at it?). So your plan lgtm. Note you'll need to release the packages where you updated the dependencies (probably via the patch version since this is akin to a bug fix).. but even then it's impossible to avoid bustage as consumers need to upgrade to pick it up.

(In reply to Andrew Halberstadt [:ahal] from comment #6)

For in-tree stuff those version specifiers aren't used anyway (we just use whatever copy exists in-tree). So this will only affect out-of-tree consumers like mozregression.

I ran into an issue on try with the chrome perftests on android where the logs showed that mozdevice 4.0.0 was being installed but when mozharness tried to instantiate mozdevice, it used the older incompatible version. I didn't understand how that happened and it seemed only to occur for the chrome tests.

I agree that we should ensure we don't automatically upgrade to the next major version (maybe we should do this for all those packages while we're at it?). So your plan lgtm. Note you'll need to release the packages where you updated the dependencies (probably via the patch version since this is akin to a bug fix).. but even then it's impossible to avoid bustage as consumers need to upgrade to pick it up.

Looking at the various dependencies for the packages, let's handle setting the maximum versions on packages separately.

I'll go ahead and file bugs for version bumps for marionette-harness, mozpower and mozrunner which directly depend on mozdevice. mozperftest and raptor do not have packages released on pypi and I think we can ignore them with regard to the package version.

We will have to do new releases as part of bug 1486004 soon as well. Sorry.

https://hg.mozilla.org/mozilla-central/rev/8360b8624b8f

Just to confirm, I do not need to have this patch uplifted to the other repos?

No, they're just released from central.