To further distill your points, there is fundamentally two problems:
1. Maintaining backwards compatibility while providing support for new features;
2. Providing security updates without breaking compatibility.
I need my flame-suit because, if Mozilla can't solve those two problems, then they seem to be ignorant of some very basic strategies in software development.
In web-based application development lately, you see a lot of "MVC" talk. MVC is far from a new concept, but more people are starting to see the wisdom of keeping your business logic separate from your UI logic.
There's no reason why a web browser shouldn't be constructed the same way. Internally, it should be separated into distinct parts -- the network interface, the rendering engine, the user interface, etc. -- with those parts communicating only through a largely static API. Each of those parts should then endeavor to separate the security-related logic from the rest of the application logic.
In other words, there is absolutely no reason why it should be impossible to apply and maintain security fixes to multiple versions of the code base, simultaneously.
Once upon a time, programmers saw the wisdom of maintaining separate versions of their applications, and they helped their system administration brethren by signaling the impact of changes in the version numbering:
major.minor.revision
Sysadmins running a specific major.minor of an application could always feel comfortable blindly updating .revisions, which typically consisted of things like security updates. If a .revision ever broke anything at all, the developers were generally considered to have screwed up.
Sysadmins could more leisurely apply major.minor updates, after double-checking that the .minor change didn't break any of the stuff that their network relied on.
And, meanwhile, sysadmins could even more leisurely take their time in developing comprehensive testing periods and update roadmaps for major releases, so that nobody in the company would get caught with their pants down.
So, not only is Mozilla committing an egregious error in not being able to apply just security updates without changing any other application functionality, but they're committing a whole other sin of long-standing software best practices by abandoning the most sensible version numbering system that was ever developed, and developed for damn good reason.
I think it's clear that Mozilla simply doesn't give a shit about their users at this point. They are either accidentally or intentionally ignorant of why these practices were developed and what problems they were intended to solved, not only in corporate markets but in home users as well. Mozilla is also digging the graves of system administrators everywhere who pushed for deployment of Mozilla applications in corporate environments and are now going to be faced with nothing less than a huge fucking maintenance nightmare -- and I promise you that nearly every corporate IT department has an administrative overlord who is much less interested in why a particular software product is technically better than they are in what the cost will be or how many people are going to complain.
I'm beyond furious, personally. Way, way beyond furious. I've been making similar comments in every single Mozilla-related thread since this was announced. My company was still switching our clients -- clients who work with us because they trust our judgement -- to Firefox as of last week. This new release strategy has just fucked us in the ass. As of now, we've completely halted Firefox conversions, and I have to figure out what to do next.
As far as website compatibility goes, would it really be so hard to support a simple comment tag at the top of the page that listed the browser major versions that the site had been built for, and then -- because the application was designed well so as to be capable of such magic as this -- use the appropriate rendering engine, dynamically loaded?
Your proposed approach of always shipping all the rendering engines you have ever had is exactly what IE is doing.
This has two drawbacks:
1) It makes your app huge (because you have to support many wildly different modes, some of which have different architecture requirement). Clearly less of a problem if your app comes preinstalled with the OS anyway.
2) If everyone were to adopt it, it significantly raises the bar for a new entrant into the browser market: instead of just implementing the specs, it would have to reverse-engineer a bunch of legacy modes. This is actively bad for the web, and a major reason why Gecko, WebKit, and Presto are NOT taking this approach.
For the rest, I understand the situation you're in, and it's unfortunate. But your claims about how browsers _should_ be architected assume that things like the web's security model or the general feature set browsers need to support are somewhat static. They're not, and changes to them can require significant architecture changes. Basic things like the in-memory representation of the DOM are being actively changed in WebKit and Gecko every so often, as new requirements come up; I can't speak to Presto and Trident because I can't see the code. Which means that porting security fixes becomed pretty difficult, because your APIs in the old release are different, your code flow in the old release is different, and most importantly the invariants the old release maintains are different, because the specs that determine those invariants have changed in the interim.
There is no way to separate out security from the other software layers. In a web applications and user agents everything is involved with security. I agree it would be great if they provided security fixes for obsolete releases but let's not pretend it would be cheap or easy. Someone would have to pay for that, the open source community is unlikely to deal with that level of configuration management drudgery for free.
> There is no way to separate out security from the other software layers.
Are you sure that's not the underlying cause of the problem?
Security is a lot like scalability and fault tolerance: you have to plan your software architecture to support it systematically. You can't just bolt it on later.
To further distill your points, there is fundamentally two problems:
1. Maintaining backwards compatibility while providing support for new features;
2. Providing security updates without breaking compatibility.
I need my flame-suit because, if Mozilla can't solve those two problems, then they seem to be ignorant of some very basic strategies in software development.
In web-based application development lately, you see a lot of "MVC" talk. MVC is far from a new concept, but more people are starting to see the wisdom of keeping your business logic separate from your UI logic.
There's no reason why a web browser shouldn't be constructed the same way. Internally, it should be separated into distinct parts -- the network interface, the rendering engine, the user interface, etc. -- with those parts communicating only through a largely static API. Each of those parts should then endeavor to separate the security-related logic from the rest of the application logic.
In other words, there is absolutely no reason why it should be impossible to apply and maintain security fixes to multiple versions of the code base, simultaneously.
Once upon a time, programmers saw the wisdom of maintaining separate versions of their applications, and they helped their system administration brethren by signaling the impact of changes in the version numbering:
major.minor.revision
Sysadmins running a specific major.minor of an application could always feel comfortable blindly updating .revisions, which typically consisted of things like security updates. If a .revision ever broke anything at all, the developers were generally considered to have screwed up.
Sysadmins could more leisurely apply major.minor updates, after double-checking that the .minor change didn't break any of the stuff that their network relied on.
And, meanwhile, sysadmins could even more leisurely take their time in developing comprehensive testing periods and update roadmaps for major releases, so that nobody in the company would get caught with their pants down.
So, not only is Mozilla committing an egregious error in not being able to apply just security updates without changing any other application functionality, but they're committing a whole other sin of long-standing software best practices by abandoning the most sensible version numbering system that was ever developed, and developed for damn good reason.
I think it's clear that Mozilla simply doesn't give a shit about their users at this point. They are either accidentally or intentionally ignorant of why these practices were developed and what problems they were intended to solved, not only in corporate markets but in home users as well. Mozilla is also digging the graves of system administrators everywhere who pushed for deployment of Mozilla applications in corporate environments and are now going to be faced with nothing less than a huge fucking maintenance nightmare -- and I promise you that nearly every corporate IT department has an administrative overlord who is much less interested in why a particular software product is technically better than they are in what the cost will be or how many people are going to complain.
I'm beyond furious, personally. Way, way beyond furious. I've been making similar comments in every single Mozilla-related thread since this was announced. My company was still switching our clients -- clients who work with us because they trust our judgement -- to Firefox as of last week. This new release strategy has just fucked us in the ass. As of now, we've completely halted Firefox conversions, and I have to figure out what to do next.
As far as website compatibility goes, would it really be so hard to support a simple comment tag at the top of the page that listed the browser major versions that the site had been built for, and then -- because the application was designed well so as to be capable of such magic as this -- use the appropriate rendering engine, dynamically loaded?