294276 - [Submission] AMO should let developers publish future-compatible add-ons or fix them automatically

Status: RESOLVED FIXED

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

Description

[Myk Melez [:myk] [@mykmelez]]

There are good reasons for developers to make their extensions compatible with
unreleased versions of host applications.  Developers may have access to release
candidates of upcoming versions and be able to certify their extensions'
compatibility.  Or they may be sure enough of compatibility (especially with
minor version bumps).

In both cases, accepting future-compatible extensions is a better user
experience.  In the first case, it means that an extension update will be
available the moment users upgrade to the newer version of the host application.
 In the second case, it means users won't have to repeatedly upgrade needlessly
every time a new version of the host application is released.

Of course, the final version of a host application could change from its release
candidates in a way that breaks some extensions that worked with those
candidates, and future versions of a host application (including minor version
bumps) could do the same.

But 99% of the time, when an extension author thinks an extension will be
compatible with future versions of a host application, it will be, and users
will be better off when we optimize for the 99% case (letting them install
future-compatible extensions, accepting the occasional bustage) than the 1% case
(making users upgrade all their extensions every time they upgrade their host
application, and not letting extension authors make new versions of extensions
available until the new version of the host application has been released, so
that early host application adopters find their existing extensions disabled and
no immediate way to fix that).

addons should let extension authors publish future-compatible extensions.

Comment 1

[alanjstr]

We already allow people to post extensions that work with trunk builds.  There
is no need for a new release of the extension when a new browser is released. 
You can change the maxVersion via the website.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

>There is no need for a new release of the extension when a new browser is 
>released.  You can change the maxVersion via the website.

That's reasonable if host applications automatically verify the compatibility of
an extension without making the user jump through any hoops and if extension
authors can mark their extensions compatible with the newer version of the host
application before that application is released.

But it's still suboptimal to second-guess extension authors' intentions and
reject future-compatible extensions.  addons should either warn extension
authors of their dangers or, if such dangers are really so severe as to be
unacceptable risks, it should automatically fix the version string of a
submitted future-compatible extension to the most recent acceptable value.

Comment 3

[alanjstr]

> That's reasonable if host applications automatically verify the compatibility of
> an extension

They should be contacting VersionCheck which would tell them it is now compatible.

> authors can mark their extensions compatible with the newer version of the host
> application before that application is released.

If the appliaction drivers work with UMO, then we can add the latest release to
our site before the official release.  For 1.0.x, the app.extensions.version is
1.0.  What is the value for 1.0+?  What will be the value for 1.1?

> But it's still suboptimal to second-guess extension authors' intentions 
It is suboptimal to tell millions of people that something is compatible when it
is not.  That is why we do all this testing/

> it should automatically fix the version string of a
> submitted future-compatible extension to the most recent acceptable value.
We do this for 1.0.x releases.  The span of 1.0+ is so vast that something can
easily work on one day and be broken the next.  We do our best to test.  

We're trying to protect the millions of downloaders.  The hundreds of authors
must all play by the same rules.  Unfortunately, this isn't documented anywhere
other than the various bugzilla bugs.  

Comment 4

[Myk Melez [:myk] [@mykmelez]]

> It is suboptimal to tell millions of people that something is compatible when
> it is not.

True, but 99% of the time it is compatible, so it makes more sense to err on
that side.

> > it should automatically fix the version string of a
> > submitted future-compatible extension to the most recent acceptable value.
> We do this for 1.0.x releases.

That didn't work for me.  When I tried to submit an extension today whose
maxVersion for Thunderbird was 1.0.9, the submission failed with the message
"Error! The MaxAppVer for Thunderbird of 1.0.9 in install.rdf is invalid."  No
apparent attempt was made to change that to another version string that addons
considers valid.


> We're trying to protect the millions of downloaders.  The hundreds of authors
must all play by the same rules.

Sure, I'm not suggesting special rules for anyone or anything that would assail
our users.  I'm just suggesting that extension authors are generally capable of
making decisions like what to put into the maxVersion string and that it makes
no sense to arbitrarily prevent them from doing so.

Authors don't want their apps to break either, so you can count on them to do
what you expect them to do most of the time and generally do something else only
for good cause.  You need not force it to obtain the right behavior here, and
you shouldn't, because it prevents anyone who has a good reason for doing so
from every doing something else.

As Jon Postel said of robust protocol design, "be conservative in what you do,
be liberal in what you accept from others."

We should let extension authors decide what to put into their maxVersion
strings, warning them when we think the value they put into that string is
inappropriate, but not preventing them from doing so.  But, if that isn't
acceptable, we should at least be auto-correcting the value rather than merely
rejecting the submission.

But perhaps I can't get you to see this position, in which I'd like to appeal to
the module owner to make a decision.  cc:ing kveton.

Comment 5

[Scott Kveton]

Myk is right.  We need to err on the side of allowing extension developers to
put what they need, etc.  If they put something silly in, our moderation should
catch it but today they can't even do that.

Unfortunately the workflow is broken today and we're not going to fix it for
v1.0.  However, we'll put this in for the list of requirements for v2.0 of UMO
which we'll be starting development on soon.

Comment 6

[alanjstr]

Well, when do we allow this in?  Do we allow someone to submit something marked
as 1.1 compatible as soon as 1.0 comes out?  Then it stays on the DB as 1.1
compatible even if it isn't.

Comment 7

[Scott Kveton]

Again, this comes back to moderation.  We could ask for clarification from the
author or if they set something like "compatible with version 10,642.01" then
we'll just know they are full of hot air or they made a mistake.  We can limit
the amount of intervention by allowing the user to err on the side of progress
instead of micro-managing every little thing they do.  We want to enable the
community, not hinder it.

Comment 8

[M.J.G.]

I'm trying to upload a new version of AboutConfig. MaxVersion is set to 1.5
since I tested successfully with Thunderbird 1.5b1. Yet, addons.mozilla.org
complains about the MaxVersion. Even 1.6a1 is out already, so why am I kept from
specifying 1.5 as MaxVersion?

Comment 9

[alanjstr]

For 1.5beta, use 1.4.  For 1.6a, use 1.6

Comment 10

[Michael Morgan [:morgamic]]

Mass change - bugs to be read / (re)confirmed.

Comment 11

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 12

[Mike Shaver (:shaver emeritus)]

I'm going to mark this as FIXED, because we permit 1.5.0.* for the minor-update-guaranteed-compat case, and we will add versions for next-milestone (2.0b1 and 3.0a1 today, f.e.) as "hidden" values to permit testing against upcoming milestones.

I was tempted, though, to WONTFIX, because we will not be permitting people to say that their extensions are compatible with releases beyond the next one.  The 1.5.0.* pattern should make the important cases go away, and the rest of the edge cases are better than having someone's Firefox 2 upgrade experience suck because of an extension that was "sure" that it would work fine a few months earlier -- you know, when we were going to ship with Places... :) -- but instead detonates on first startup, embedding shards of RDF and XML errors into the user's face.