5 ms·

So here's my take on the matter. This is a Damned if you do, damned if you don't problem. a) Firefox must release frequently to keep up with competition. A fir

So here's my take on the matter. This is a Damned if you do, damned if you don't problem. a) Firefox must release frequently to keep up with competition. A firefox by any other version is just the same set of changes, just labeled 4.1 vs 5. I don't know why they changed their numbering system (to keep up with chrome i guess) but it makes absolutely zero difference. b) Any corporation cares about stability vs progress. They want to test now, guarantee that it will work for say 10 years, and just stick with it. And now of course c) The web needs to progress. (ie6). IE6 is still being used. This has been beaten long and hard for years. The problem is not IE6, the problem is corporations. IE6 will die, it'll die soon (I hope) as I still have to support that heap of crap. HOWEVER tomorrow firefox 3.6 will be it. FF 3.6 will have some crap and work like shit 10 yrs from now and some corporation will want to use it and nothing else just like IE7 and IE8 and actually anything. -- Anyone who embraces chrome is embracing a mindset, it will always be up-to-date and our it must support the latest version, we'll force a restart of chrome at some point to update that version. Our sites MUST WORK WITH LATEST CHROME. Here we have examples of companies complaining, and I guarantee if Mozilla would state that 3.6 will be forever supported (7 yrs?) like IE6 was they would get the same shit MS got for IE6, sure not today, but in a few yrs "omg fucking ff 3.6 can't do shit like rounded corners right, it needs to die" followed by the FF3.6 eulogy website etc. The only way to win this is for companies to realize that the following will be true on the web: a) security vulnerabilities in browsers will be discovered/patched, and quickly. You must upgrade frequently to keep up. b) The web is moving forward, even if you dislike that. Due to this rendering engines must be updated constantly. Sorry. Adopt best practices and release frequently. Its an unfortunate cold hard truth and its costly but its the nature of dealing with the web. c) Mozilla can't support an old browser forever. Pay them and they will. However they are not Microsoft, and even MS can't do this effectively, so if you want something for "free" (IE included here) be prepared for paying for having to move in the direction they take. Otherwise contribute cash to them to support what you want. I'm sure Mozilla will happily create a special FF3.5 branch back-porting fixes for years as long as you pay them to.

zaphar 15y ago
I would argue that the Chrome mindset may actually be a more sustainable easier practice. Instead of a large "certification" process you just fix things as they break on an ongoing basis. Small changes over time seem easier to absorb than a Huge change once every few years.
- icefox 15y ago
  Not to mention they would only have one version of chrome (the latest) to support and not multiple versions of Firefox that are still installed on various desktops around the office.
thaumaturgy 15y ago
Let me put my flame-suit on ... 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?
ebiester 15y ago
Let's play a little game here. Assume a corporation is creating over 100 custom applications to support businesses over dozens of product divisions, and any time supports over 1,000 internal applications, dating back to COBOL. The COBOL applications keep working. The ColdFusion apps keep working. The VB6 apps are supported on an XP development box, but they still work on Windows 7. People are planning the replacement applications right now. And then there's Mozilla. A feature introduced in 6 gets deprecated in 11, or changed just enough. Suddenly, 50 applications have an immediate need to change before there are any security bugs found in 10. After all, 10 is EOL and security bugs wont' be updated. The idea of a long term release (supported X years) is a good one. Enforced bit rot and continual QA on legacy apps sucks, but having to do it every few months is untenable. On the other hand, about 50 people see a market opportunity right about now. :)
- mindcrime 15y ago
  On the other hand, about 50 people see a market opportunity right about now. :) Well, enterprisefox.com and enterprisebrowser.com are both already registered, so basically, yeah. :-)

zaphar 15y ago

I would argue that the Chrome mindset may actually be a more sustainable easier practice. Instead of a large "certification" process you just fix things as they break on an ongoing basis. Small changes over time seem easier to absorb than a Huge change once every few years.

icefox 15y ago
Not to mention they would only have one version of chrome (the latest) to support and not multiple versions of Firefox that are still installed on various desktops around the office.

thaumaturgy 15y ago

Let me put my flame-suit on ... 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?

ebiester 15y ago

Let's play a little game here. Assume a corporation is creating over 100 custom applications to support businesses over dozens of product divisions, and any time supports over 1,000 internal applications, dating back to COBOL. The COBOL applications keep working. The ColdFusion apps keep working. The VB6 apps are supported on an XP development box, but they still work on Windows 7. People are planning the replacement applications right now. And then there's Mozilla. A feature introduced in 6 gets deprecated in 11, or changed just enough. Suddenly, 50 applications have an immediate need to change before there are any security bugs found in 10. After all, 10 is EOL and security bugs wont' be updated. The idea of a long term release (supported X years) is a good one. Enforced bit rot and continual QA on legacy apps sucks, but having to do it every few months is untenable. On the other hand, about 50 people see a market opportunity right about now. :)

mindcrime 15y ago
On the other hand, about 50 people see a market opportunity right about now. :) Well, enterprisefox.com and enterprisebrowser.com are both already registered, so basically, yeah. :-)