817196 - Implement way for reviewers to test app upgrade process

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Reviewer Tools, enhancement, P5)

Description

[Rob Hudson [:robhudson]]

It was brought up in a meeting that it would be useful to allow reviewers to install the current public version of an app (or, possibly, any prior version), and then trigger an update to update the version to the current version that is under review. This would allow reviewers to verify that the app takes the appropriate cautions to maintain, etc. data between versions.

For this to work we need to allow reviewers to select which version of an app is currently pointed to by the mini-manifest. The reviewer would select an old version, install it, then select the current in-review version, and trigger an update.

Note: I don't know if there is currently a way on device to trigger an app update.

Comment 1

[Rob Hudson [:robhudson]]

(In reply to Rob Hudson [:robhudson] from comment #0)
> Note: I don't know if there is currently a way on device to trigger an app
> update.

Fabrice has told me this is at: settings > device info > check for updates > "Check now"

Comment 2

[Wil Clouser [:clouserw]]

Jeff - is this a requested feature?

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, if we can get something like this that would be awesome. This is basically what I had envisioned too. Now that bug 796198 is fixed, the marketplace should be able to use cookies to detect when a reviewer is accessing a minimanifest and set the selected version of the manifest at that point.

And yes, this is definitely a new feature, so I understand that this is problematic.

Solving things this way rather than on the device has the advantage that we have more flexibility in adjusting the reviewing process if what we come up with turns out to not work that well.

Comment 4

[Andrew Williamson [:eviljeff]]

I'm not clear on the 'trigger an update' bit.  As in an automatic check on the device to the version under review?  This sounds cool but also complicated and liable to breakage later.

Being able to manually install any version is a requirement; and I guess we will be able to manually install an under-review version over an existing public one?  That's sufficient.

Comment 5

[Rob Hudson [:robhudson]]

The way upgrades and packaged app works is it uses the URL to the mini-manifest. Currently, the URL to the mini-manifest for reviewer-signed packaged apps has the version ID in it. I did that so upgrades wouldn't happen automatically and reviewers can install the specific version under review (which is always the latest version).

This would update the way this works such that:
* There is only 1 mini-manifest for reviewer-signed packaged apps.
* Allow the reviewer to choose which version the mini-manifest points to (perhaps defaulting to the latest).

With the above you could test specific versions, as well as the upgrade process by swapping the version and triggering an update on device.

Comment 6

[Rob Hudson [:robhudson]]

(In reply to Andrew Williamson [:eviljeff] from comment #4)
> I'm not clear on the 'trigger an update' bit.  As in an automatic check on
> the device to the version under review?  This sounds cool but also
> complicated and liable to breakage later.

"Trigger an update" would be going to settings > device info > check for updates > "Check now" on the device. Since the mini-manifest URL was saved on device at install time, it will hit the same URL asking if there are updates.

As it is currently implemented there will never be an update because we have the version ID in the URL. The plan is to use a single URL for the mini-manifest so it can point to different versions so there could be an update.

> Being able to manually install any version is a requirement; and I guess we
> will be able to manually install an under-review version over an existing
> public one?  That's sufficient.

No, you will not be able to manually install an under-review version over an existing public one because public packaged apps have a different URL to the mini-manifest. Because of this the device will only ping the public mini-manifest for updates.

But with the proposed changes in this bug you will be able to install any version. And also install an under-review version over an existing one where the existing one is a prior version chosen from the reviewer tools.

Comment 7

[Andrew Williamson [:eviljeff]]

(In reply to Rob Hudson [:robhudson] from comment #6)
> No, you will not be able to manually install an under-review version over an
> existing public one because public packaged apps have a different URL to the
> mini-manifest. Because of this the device will only ping the public
> mini-manifest for updates.

What happens now if I tried to install an under review version of an app when I have a public version already installed?  Will I get two app installations?  Will it fail?  (not using the check for updates feature, just using marketplace)

> But with the proposed changes in this bug you will be able to install any
> version. And also install an under-review version over an existing one where
> the existing one is a prior version chosen from the reviewer tools.

That sounds good.  What would be the proposed method of selecting which version to update to?

Comment 8

[Rob Hudson [:robhudson]]

(In reply to Andrew Williamson [:eviljeff] from comment #7)
> What happens now if I tried to install an under review version of an app
> when I have a public version already installed?  Will I get two app
> installations?  Will it fail?  (not using the check for updates feature,
> just using marketplace)

My guess is you will get 2 app installations since they are from separate origins (URLs to the mini-manifest).

> That sounds good.  What would be the proposed method of selecting which
> version to update to?

I was thinking do 2 things:
1. Update the install button to say which version it is currently pointing to. E.g. "Install v2.0".
2. Underneath have a select box that lists all versions and when changed triggers a back-end update and page refresh to point the mini-manifest at the selected version.

Comment 9

[Wil Clouser [:clouserw]]

> I was thinking do 2 things:
> 1. Update the install button to say which version it is currently pointing
> to. E.g. "Install v2.0".
> 2. Underneath have a select box that lists all versions and when changed
> triggers a back-end update and page refresh to point the mini-manifest at
> the selected version.

I think that makes sense with a (?) after it which people could mouse over and get an explanation of whats going on.  Note that this is a low priority enhancement right now.

Comment 10

[Andrew Williamson [:eviljeff]]

wontfix'ing as bug 1036495 will make it very difficult to implement an upgrade when we have unique mini-manifest urls - and we'd prefer to have bug 1036495.