:jgraham reports broken web-platform tests as a result of the recent changes to mozdevice and version bumps to mozdevice 1.0.0 and mozrunner 7.0.1 -- he's seeing references to DMError, which were removed in https://hg.mozilla.org/mozilla-central/rev/a79cd8dc4c1c

Looking at bug 1434926, it looks like there is a bit of a process for marionette releases. Would you like to walk me through that, or take this bug, or should I just charge ahead with this simple change? (From my perspective, I think we just need to get new marionette-driver and marionette-harness releases on pypi ASAP.)

In general there is not such much to do for a release, but we have seen in the past that devs land changes which cause incompatibilities. That's why we have to check all the changes which happened since the last release. I can have a quick look over those in a minute. I will also adjust the bug summary so we can easily find this bug again. Just a generic version bump summary is not that helpful.

The following lists show the changes since the last releases: Marionette driver: % hg log -M -r b55d8ad0bf35:: --template "{desc|firstline}\n" . Bug 1452483 - Strip whitespace from injected scripts. r=maja_zf Bug 1452483 - Use relative path to source file for injected scripts. r=maja_zf Bug 1452597 - Remove debug_script functionality for injected scripts. r=maja_zf Bug 1440714 - Convert Android marionette tests to use adb.py; r=bc Marionette harness: % hg log -M -r b55d8ad0bf35:: --template "{desc|firstline}\n" . Bug 1434926 - Release marionette_driver 2.6.0 and marionette_harness 4.4.0. r=ato Bug 1452483 - Preserve stacktrace from sandbox evaluation. r=maja_zf Bug 1452597 - Remove debug_script functionality for injected scripts. r=maja_zf Bug 1453009 - Remove collection tests from Marionette. r=whimboo Bug 1453789: Remove Element.createShadowRoot. r=smaug Bug 1452643 - Update wptserve args in marionette runner, r=me ON A CLOSED TREE Bug 1034036 - Part 1: Merge RecentWindow.jsm and UpdateTopLevelContentWindowIDHelper.jsm into one module called 'BrowserWindowTracker.jsm'. r=dao Bug 1034036 - Part 2: Rename and shorten `getMostRecentBrowserWindow` to `getTopWindow` and modernize the style used in BrowserWindowTracker.jsm. r=d Bug 1454202: Follow-up: Fix Marionette test bustage. r=bustage,test-only Bug 1456051 - Propagate OS errors on addon installation. r=maja_zf Bug 1440714 - Convert Android marionette tests to use adb.py; r=bc Bug 1456520 - Make test_capabilities.py more resilient to mozdevice changes; r=bc,whimboo So far as I can see those changes look all fine.

Comment on attachment 8972369 [details] [diff] [review] version bump for marionette Review of attachment 8972369 [details] [diff] [review]: ----------------------------------------------------------------- r=me with the comments addressed. ::: testing/marionette/client/marionette_driver/__init__.py @@ +4,4 @@ > > from __future__ import absolute_import > > +__version__ = '2.6.1' Also update the Marionette harness requirements.txt file so that this version is the minimum allowed one.

Oh, and also bump the minimum versions of mozrunner and mozdevice in the requirements.txt of the driver and harness.

Discussed with :whimboo on irc -- decided a minor release was more appropriate.

FWIW, I don't think that in semver you can bump the major version of a python dependency without bumping the major version of the package depends on it. There are a couple of reasons for this: * Unless you are very careful the dependency is exposed as part of the public api of the top level package e.g. if bar depends on foo, I can probably do `from bar import foo` or access types from foo somee other way e.g. via unhandled custom exceptions. * More importantly, Python only allows one version of a package at a time (unlike node and Rust, for example). So if I write a package baz that depends on bar >=1 <2 and on foo >=1 <2 and where bar itself also depends on foo >=1 < 2 and then release bar 1.1 that depends on foo >=2 <3, I end up with incompatible requirements on foo just from upgrading a minor release. These things break the central promise of semver that you can upgrade non-major versions of depenendcies without problems. (FWIW I'm not suggesting we block on this change; I think my position is that getting semver right with Python is really hard and so I'm not that enthused about trying to enforce it).

(In reply to James Graham [:jgraham] from comment #8) > getting semver right with Python is really hard That has certainly been my experience this week! But that's more than semver: It is also my inexperience with mozrunner and marionette and my lack of appreciation for all the dependencies on the original mozdevice change. I think I'll push ahead with what I have here and hope this is the last change required.

(In reply to James Graham [:jgraham] from comment #8) > (FWIW I'm not suggesting we block on this change; I think my position is > that getting semver right with Python is really hard and so I'm not that > enthused about trying to enforce it). I do agree it's hard, but remeber that we're changing from no versioning process whatsoever. Under the previous system every package had unbounded dependencies. This was really bad because as soon as we made a breaking change in a dependency all those old versions with unbounded dependencies were permanently busted. I hit a case of this happening in the wild which is what prompted me to start adding upper limits on the dependencies. SemVer, while not perfect and potentially difficult to implement, was at least a widely understood system with a moderate improvement over the status quo. Even if we aren't 100% accurate with it, at least it's a vague signal of intent (whereas previously there was no signal whatsoever).

I'm not convinced that a "vague signal of intent" is a meaningful improvement over no signal at all, if the vauge signal is often directly misleading. In this specific case I upgraded wptrunner from 7.0.0 to 7.0.1 without much thought because that was "safe". Except it actually broke everything. This is in a consumer with all deps pinned to specfic versions, which eliminates most of the problems of the old system, except that one tends to end up on old versions of things after a while. Anyway, I'm not going to argue about this; if semver works it will be good. But I think it will be a struggle to get right given our situation.

Pushed by gbrown@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/721395128428 Release marionette_driver 2.7.0 and marionette_harness 4.5.0; r=whimboo

:whimboo -- I do not have permissions to update these pypi projects. I'm happy to upload if you add me as a maintainer, or perhaps you can do the upload?

Both packages have been uploaded: Uploading marionette_driver-2.7.0-py2-none-any.whl Uploading marionette_driver-2.7.0.tar.gz Uploading marionette_harness-4.5.0-py2-none-any.whl Uploading marionette-harness-4.5.0.tar.gz