setting maxVersion to *
Myk Melez
In recent discussions between some AMO and Jetpack folks, we concluded that Add-on SDK-based addons should have their maxVersions set to * so they are marked as forward-compatible with future versions of Firefox, since:
- the SDK exposes high-level APIs that are designed to remain
forward-compatible across low-level implementation changes;
- the Jetpack team plans to update the SDK as needed to maintain
forward compatibility as new versions of Firefox are developed
and released;
- AMO plans to automatically update addons distributed on that site to use newer versions of the SDK as those versions become available.
This change will also make it easier for the SDK to accommodate Firefox's new rapid release schedule, which will result in frequent Firefox version changes.
I have filed bug 649692 on the change, which also requires us to change AMO to accept SDK-based addons with that designation, for which I have filed bug 649695.
This is different from what we've done in the past. But I think it's the right thing to do. Questions, comments, concerns? Let's talk!
-myk
Benjamin Smedberg
Rocketeers!
In recent discussions between some AMO and Jetpack folks, we concluded that Add-on SDK-based addons should have their maxVersions set to * so they are marked as forward-compatible with future versions of Firefox, since:
- the SDK exposes high-level APIs that are designed to remain forward-compatible across low-level implementation changes;
- the Jetpack team plans to update the SDK as needed to maintain forward compatibility as new versions of Firefox are developed and released;
- AMO plans to automatically update addons distributed on that site to use newer versions of the SDK as those versions become available.
This sounds half-baked.
--BDS
Myk Melez
> This is all true, but what has it got to do with the maxversion that
> is reported for the extension which is installed in firefox "right
> now"? e.g. if you are running Firefox 5 and then you install Firefox
> 6, the addons you have right now may not be compatible. You may need
> to go to AMO, get the automatically-fixed addon, and use that. In the
> meantime, the old version may break firefox.
the older version of the SDK should have been updated by AMO to use the
newer version of the SDK, and Firefox 5 should have installed the
updated version of the addon, so there should be no intermediary period
during which time the installed version of the addon is incompatible
with the installed version of Firefox and breaks it.
This does assume that an update to the SDK maintains backward
compatibility with older versions of Firefox. If we update the SDK to
support Firefox 6, and we have to break support for Firefox 5 in the
process, then AMO can update the addon to use the newer version of the
SDK, but Firefox 5 won't install that update, so the addon will break
Firefox when the user installs Firefox 6, until Firefox installs the
updated addon (if Firefox is not too broken to do so).
That case seems unlikely, but it is a problem with the proposed approach.
> This sounds half-baked.
Then let's continue baking it! ;-) (Hence this thread.)
-myk
Nickolay Ponomarev
On 04/13/2011 03:46 PM, Benjamin Smedberg wrote:By the time Firefox 6 is available for you to install, addons that used the older version of the SDK should have been updated by AMO to use the newer version of the SDK, and Firefox 5 should have installed the updated version of the addon
This is all true, but what has it got to do with the maxversion that is reported for the extension which is installed in firefox "right now"? e.g. if you are running Firefox 5 and then you install Firefox 6, the addons you have right now may not be compatible. You may need to go to AMO, get the automatically-fixed addon, and use that. In the meantime, the old version may break firefox.
Still it sounds like it's the *automatically-updated XPI* that should have the bumped maxVersion, not the original, incompatible with Firefox.N+1, XPI.
What if the user doesn't update the extension before updating Firefox? What if the new version of the SDK isn't ready in time (e.g. if the user is on a prerelease Firefox version)? What if the new version of the SDK has to change a high-level API unexpectedly? What if the user tries to install an out-of-date XPI incompatible with the current Firefox version?
In all these cases the incompatible extension would be disabled if it used the correct maxVersion and there would be a clear message displayed to the user as to why it's not working.
Nickolay
Benjamin Smedberg
> By the time Firefox 6 is available for you to install, addons that
> used the older version of the SDK should have been updated by AMO to
> use the newer version of the SDK, and Firefox 5 should have installed
> the updated version of the addon, so there should be no intermediary
> period during which time the installed version of the addon is
> incompatible with the installed version of Firefox and breaks it.
mean that on any particular computer it *has* been done: I think we
should use maxversion very specifically for the maximum version that the
currently-installed thing is known to support. Then AMO can continue to
bump the maxversion as it does today if no SDK changes are needed, or
repack with the new SDK with new min/maxversion IDs as appropriate.
--BDS
Atul Varma
constantly upgrade maxVersion in the git repository?
If so, I think we've talked about potential ways to make that less of a
hassle on the jetpack team--there may even be a bug on it. Would a
lightweight solution for that make it easier to make maxVersion changing
a bit more agile? Perhaps a privileged "bot" that simply runs the test
suite on a new version of Firefox and automatically changes maxVersion
if all the tests pass?
Or does this proposal have something to do with the new "train" model
for Firefox releases?
While part of me would really love to set maxVersion to *, I'm having a
hard time poking through Nickolay and Benjamin's arguments. ;)
- Atul
Myk Melez
> What if the user doesn't update the extension before updating Firefox?
> What if the new version of the SDK isn't ready in time (e.g. if the
> user is on a prerelease Firefox version)? What if the new version of
> the SDK has to change a high-level API unexpectedly? What if the user
> tries to install an out-of-date XPI incompatible with the current
> Firefox version?
>
> In all these cases the incompatible extension would be disabled if it
> used the correct maxVersion and there would be a clear message
> displayed to the user as to why it's not working.
On 04/14/2011 06:24 PM, Benjamin Smedberg wrote:
> I'll echo what Nickolay said: the fact that AMO "will" do this doesn't
> mean that on any particular computer it *has* been done: I think we
> should use maxversion very specifically for the maximum version that
> the currently-installed thing is known to support. Then AMO can
> continue to bump the maxversion as it does today if no SDK changes are
> needed, or repack with the new SDK with new min/maxversion IDs as
> appropriate.
These are all good points, and having made this decision in haste, I'll
buck the trend and repent as quickly.
It sounds like the better plan is indeed to continue to set the SDK's
Firefox maxVersion to the latest version of Firefox with which the SDK
is known to be compatible, then update it and ship updates to the SDK as
needed.
This may suggest revisions to our plan to repack AMO-distributed addons
when the SDK is updated.
We haven't worked out a post-1.0 release schedule, but if we were to
ship the SDK as often as Firefox, AMO could maintain addon compatibility
as per the existing plan, by repacking addons as soon as a new version
of the SDK is released, f.e. at the beginning of the beta cycle for the
Firefox release, or whenever the Firefox/platform teams commit to
maintain API compatibility for the release.
However, we could also ship SDK releases less frequently, provided there
were no breaking changes in Firefox updates, and AMO could automatically
bump the maxVersions of addons instead of repacking them.
-myk