526077 - Implement Release Channels

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, defect, P1)

Description

[Nick Nguyen [:osunick]]

http://docs.google.com/Doc?docid=0Ad7mAOXgEBZyZGRzNnZ3YjRfMmc4ZGd3c2Mz&hl=en

Designs coming shortly

Comment 1

[Jeff Balogh (:jbalogh)]

Talked to Nick, some changes/comments:

(1.4) We're going to add a new box between "More about this add-on" and "Reviews" that has the install button for beta channels.  It should have an anchor so it's easy to link, but it's ok to be semi-hidden down there.

(1.6) Consecutive versions of a beta should be tagged X.Ybeta, X.Ybeta2, ...

(1.9) The update URL won't change between channels.  We'll inspect the user's current version to figure out what channel to serve.

Comment 2

[Ed Lee :Mardak]

In terms of migration, if users are currently on a version with "beta," they'll get updates to the "beta" channel once this rolls out? (This is more in terms of currently we host "beta" versions off of AMO and after this is implemented, we can just remove the update url and firefox will ask AMO, and AMO will respond with the appropriate channel's xpi?)

Currently on Weave's "stable" track (AMO), we have versions: 1.0b1, 0.8, 0.7, ..
The "dev" track has versions: 1.0b1pre1, 0.8pre1, 0.8pre2, 0.7pre1, ..

It's just a naming convention, so we can also change that to fit what AMO expects, but doing "0.8beta1" might invoke a stronger "almost complete" feeling than "0.8pre1".

Our "stable" releases are ~1 month and "dev" are ~1 week cycles, but potentially we would want "nightly" versions. Would that not be differentiated in the first implementation of release channels?

Comment 3

[Ed Lee :Mardak]

Oh, and also at some points the "stable" and "dev" tracks are at the same version, e.g., 0.8, but internally the add-on knows that it's on stable vs dev. But if what we're doing here is detecting channel by version, "dev"-users wouldn't get the latest 0.8. A workaround would be to just have a dummy version that is equivalent, e.g., 0.8beta+.

Comment 4

[Neil Lee [:neilio]]

Attachment: Mockup of beta release version in add-on details box

Here's a mockup of how we could add this to the add-on details box.

Comment 5

[Ed Lee :Mardak]

What would getting the "latest" xpi do if you have 0.8 and 0.8b1 uploaded to AMO?

Comment 6

[Nick Nguyen [:osunick]]

The workaround is right- you'd have to upload the same file as two separate version numbers if you want it in both channels.  This is the only way we could do this with the existing update infrastructure.

Comment 7

[Nick Nguyen [:osunick]]

<- regarding comment 3, we decided to support a fixed number of release channels- "primary and beta" and may extend this to an arbitrary number if demand warrants it.  The reason for this decision was that it made the UI much simpler.

Comment 8

[Jeff Balogh (:jbalogh)]

(In reply to comment #5)
> What would getting the "latest" xpi do if you have 0.8 and 0.8b1 uploaded to
> AMO?

It should get the latest from the primary channel, but that's something I'll have to be sure to check.  Thanks.

Comment 9

[Jeff Balogh (:jbalogh)]

Attachment: beta channels

The text and layout is still up in the air, waiting on nick.

Comment 10

[Nick Nguyen [:osunick]]

Warning text:

"Beta versions of this add-on have not been reviewed by Mozilla.  Once you install a beta version you will continue to receive beta updates from this developer.  To switch back to the normal version of this add-on, click on the "Add to Firefox" button at the top of this listing."

Comment 11

[Jeff Balogh (:jbalogh)]

Attachment: beta channels

Comment 12

[Dave Garrett]

Would it be possible to change the regexp to match for beta versions from /beta\d*$/ to /(alpha|beta|pre)\d*$/ to allow for more flexibility in the versioning? (or would you reserve one or more of those for future channels?)

Comment 13

[Ed Lee :Mardak]

Oh, and any particular reason for the $ match?

Comment 14

[Dave Garrett]

Or even every prerelease version under the sun in one channel: /(a|alpha|b|beta|pre|rc)\d*$/

Allowing "rc" would sidestep the beta=release problem noted above. The final RC pushed to the dev channel would be the one used for the release.

Comment 15

[Jeff Balogh (:jbalogh)]

(In reply to comment #13)
> Oh, and any particular reason for the $ match?

Mostly because I like to keep my regexen anchored.  What would you like to put after the number?

Comment 16

[Jeff Balogh (:jbalogh)]

(In reply to comment #14)
> Or even every prerelease version under the sun in one channel:
> /(a|alpha|b|beta|pre|rc)\d*$/
> 
> Allowing "rc" would sidestep the beta=release problem noted above. The final RC
> pushed to the dev channel would be the one used for the release.

I went with "beta" for simplicity.  The original spec called for as many release channels as you can dream up, but we didn't think the added complexity (for us and for users) was worth it.

I'd imagine that the normal workflow would be point release -> beta -> point release, but larger add-ons want more incremental releases before beta.  Currently, AMO doesn't care what your version numbers are; it thinks the latest version is the most recently uploaded.  We could continue this scheme but pull out all the patterns Dave listed to the "Beta" channel.

I'm hesitant to do this only because it adds complexity for people installing the add-on (is this an alpha, beta, rc, pre...wtf do those mean?).  We've recently talked about making AMO easier for people who aren't advanced, and this wouldn't help.  But I'd imagine the people who go for a "Beta Channel" would be fine.

What do you think nick?

Comment 17

[Ed Lee :Mardak]

I believe the suggestion was to have all those alpha/beta/pre/rc in the "beta" channel because they're not release ready (except maybe rc).

The non-anchored isn't a big issue, but this is saying that only the last (of up to 4 dotted sections) is used to determine beta-ness.

Comment 18

[Wil Clouser [:clouserw]]

Comment on attachment 413239 [details] [diff] [review]
beta channels

I guess we finally hit the use case where we should have separated add-on statuses from file statuses, huh?  

Anyway, it's not working for me.  After applying your patch and making no changes to id 5326 I see this at the top of the page:

Notice: Undefined offset: 0 in /home/clouserw/public_html/addons.mozilla.org/site/app/models/addon.php on line 366

And then the whole "Beta Channel" section with another undefined index.  When I click "install beta version" it says "This add-on is not available" with another undefined index.  Since I didn't make any beta versions this whole thing should be hidden.

Comment 19

[Jeff Balogh (:jbalogh)]

Attachment: v2

Comment 20

[Wil Clouser [:clouserw]]

Comment on attachment 413427 [details] [diff] [review]
v2

This is looking good.  I noticed that if an add-on is trusted they'll never hit the logic for beta version.  I think that should be fixed (developers_controller)

Comment 21

[Jeff Balogh (:jbalogh)]

r56522 with the trusted fixes and Dave's extended regex in comment 14.

Comment 24

[Jeff Balogh (:jbalogh)]

QA: here's some fun ways to test this!

1. Upload a beta xpi (the version should match the regex in comment 14)
Check it: there should be a new section in the "More" box that lets you install the beta version
Preconditions: only public or trusted add-ons should be able to do this

2. Upload a regular version to make sure betas aren't hurting regular channels

3. Try updating from old regular version to new regular version through the addon manager, make sure you don't get a beta version.  I think you have to mess with about:config:`extensions.update.url` to use preview.

4. Same as (3), but going from old beta to new beta.  Beta channels should never get switched to the normal channel.

5. From bug 529650, make sure that unchecking "Show beta versions" from the versions page hides the the Beta box on the add-on detail page.

Comment 25

[Vishal Kamdar [:vish_moz]]

I have two  versions of beta and two versions of regular non-beta files for this addon, https://preview.addons.mozilla.org/en-US/firefox/addon/43617
Also, I did check the box 'show all beta channels', but the other channels do not show up on the addon details page. 
Hence, reopening...

Comment 26

[Wil Clouser [:clouserw]]

Vishal:  What is the problem?  This is working fine for me.

Comment 27

[Jeff Balogh (:jbalogh)]

I've uploaded two beta versions (one that I used for testing, one a modified version of what vish is using), both worked fine for me.

Comment 28

[krupa raj[:krupa]]

Jeff, can you give the URL for the test add-on you uploaded?

Comment 29

[Jeff Balogh (:jbalogh)]

The xpi is here: http://people.mozilla.org/~jbalogh/vish.xpi

I uploaded it to https://preview.addons.mozilla.org/en-US/firefox/addon/43617

Comment 30

[Wil Clouser [:clouserw]]

Talked to Krupa on IRC.  There is no problem here.

Comment 31

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot; showing update from beta 4 to 8 version

Comment 32

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot; showing successful update to beta version 8

Comment 33

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED; here's what we did to verify:

* Vishal uploaded a series of add-ons (both in the "release" and "beta" channel), by:
** modifying "<em:version>4.0beta8</em:version>" in the install.rdf for each add-on (and making it unique)
* beta versions don't show up on the version-history page (https://preview.addons.mozilla.org/en-US/firefox/addons/versions/43617)
* on https://preview.addons.mozilla.org/en-US/firefox/addon/43617, there is now the "Beta Channel

The Beta Channel lets you test an experimental new version of this add-on before it's released to the general public. Once you install the beta version, you will continue to get updates from this channel. Install beta version"
* jbalogh had to make a change (r57611) to teach the add-ons lookup code to know about beta versions, on this page: https://preview.addons.mozilla.org/en-US/admin/addons?q=MozQA+[43617]
** that bug--which caused them to show up at "incomplete", led us to change their status yet again, which threw away our testing setup
* Raymond and I uploaded a couple more beta versions
* we then flipped extensions.update.url to point to preview, and
* downloaded the beta 4 version, restarted Firefox, clicked "Check for Updates", and
* were offered and took the update to beta 8

There might be some edge cases we haven't covered, but I feel good about this being in 5.4.

Phew!