3 ms·
I think this new development process will actually be a benefit for plugin authors. Each new version will come with fewer big changes, meaning that plugins may
by owenmarshall 15y ago
I think this new development process will actually be a benefit for plugin authors. Each new version will come with fewer big changes, meaning that plugins may just keep working across different versions.
Of course, that benefit can only be realized if plugins are no longer tied to a version. A good solution is definitely needed here.
- Tyrannosaurs 15y agoThat makes no sense. If you move a product from A to B where A is compatible with a plug-in and B isn't, it doesn't matter whether you do it in one step or 10 steps, it's still going to break at some point. The positive for developers is that the smaller number of changes might make it easier to identify what's caused the problem and means that any particular release is less likely to cause a problem, the downside is that you have to retest it far more often and you have far more releases that might break something. Overall it feels slightly (though not massively) worse for developers as the total overhead of basic test, release and so on increases.
- owenmarshall 15y agohttps://developer.mozilla.org/en/Extensions/Updating_extensions_for_Firefox_4 https://developer.mozilla.org/en/Extensions/Updating_extensi... Too many at one time for me. I'd much rather be able to follow the 5->6 release cycle and test my extension over a much smaller set of changes. Other devs may disagree, that's fine and worth discussion. The key point IMO is that extension authors must be provided a way to indicate extension compatibility that isn't tied to the browser version number. The version is going to start iterating much faster, and popping up a "these extensions are broken!" box every few months will completely kill user confidence in extensions.