Code review comment for lp:~michael-sheldon/content-hub/peer-picker-updates

> I'm not entirely sure we want to have separate packages for the different
> versions as the way the QML versioning works means that the one package
> contains both versions of the API, with the files used for each controlled by
> the qmldir file (and by the C++ version registration).

Yeah, in this case from a functional point of view it all works fine, the package name is just useful for package depends (not for click). So if your app import Ubuntu.Content 1.1 you would need to have that package installed. As for keeping them around and parallel installable, it'll be much more useful when we transition to say a 2.0 API version which might not be backwards compatible and we stop carrying old versions. This way the old module can be installed as well.

We currently have 3 packages depending on qtdeclarative5-ubuntu-content0.1:
 address-book-app
 unity-webapps-qml
 ubuntu-system-settings

This can land without actually breaking apps, which is great but there isn't a clear way for any of those apps depending on package versions ensure that 1.1 is installed. And folks would likely assume content0.1 provides that API versions. However, changing that to content1.1 doesn't make it clear that it also provides 0.1, so no silver bullet there.