Thomas Lange - Sun Germany - ham02 - Hamburg, 28-01-2009 09:31:
I do not consider the implementation of a maximum version to be a fix
for not being able to uninstall/upgrade extensions, even though the API
incompatibility has happened.
If it is about updating the Office: If on the next start, after the
office update, incompatible extensions are found those should be
automatically disabled before the office gets started. Or at least they
should be disabled and then the Office automatically restarted once more
if necessary.
Firefox and Thunderbird for example seem to be able to do that...
They disable the extensions based on the maximum version defined. The
maximum version is defined within a range where Mozilla assures it won't
break anything within extensions.
If some bug is introduced somewhere and is not found until the time of
the release, the extension will run and behave incorrectly.
They release another version to fix the regression. But in the meantime,
the user have to disable the extension manually.
In this case, they have an option to launch the application without any
kind of extension or theme loading, so it's guaranteed it will startup
properly.
Then they enforce the developer to test and update the maximum version
field - compatible versions, more specifically. They allow the developer
to change it within the site they use to manage extensions - no need
from the developer to upload it again. Also the extensions are checked
for updates and updated automatically - even tough it's just to update
the compatible versions field.
So... comparing with Mozilla, they grant the possibility to
uninstall/upgrade by using the compatible versions field and enforcing
the update.
They require not bogus version numbers on the extensions hosted on
addons.mozilla.org.
Of course this solution won't work if someone uses "3.*", or "4.*" or
"10.*". But we should make the extension developers aware of the
possibility of API changes and make them use right value.
The other part of the solution is a politic of API changes. Mozilla does
not change its existing API within a major version. Most API are frozen
and only will be allowed to change within Gecko branch 2 (Firefox 4 or
possible Firefox 5).
If we are allowed to make incompatible changes to the API within "3.*",
we should allow the maximum version field to specify at least the minor
version. So the extensions would have to be tested and updated for 3.2,
3.3, etc.
No extension would be allowed to tell it's compatible with every 3.x
release.
This way, we wouldn't have such incompatibilities, except by the
extension's developer fault - by not testing properly and updating the
field.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
