Now that Mozilla has released Firefox 5, version 4, just three months old, is …

Three months ago, Mozilla released the long-awaited Firefox 4. Last week, the organization shipped the follow-up release: Firefox 5. Firefox 5 was the first version of the browser to be released using Mozilla's new Firefox product lifecycle, which would see a new version of the browser shipping every three months or so. The new policy has been publicized for some months, and so the release of Firefox 5 was not itself a big surprise. What has caught many off-guard is the support, or lack thereof. With the release of Firefox 5, Firefox 4—though just three months old—has been end-of-lifed. It won't receive any more updates, patches, or security fixes. Ever. And corporate customers are complaining.

The major problem is testing. Many corporations have in-house Web applications—both custom and third-party—that they access through their Web browsers, and before any new browser upgrade can be deployed to users, it must be tested to verify that it works correctly and doesn't cause any trouble with business-critical applications. With Mozilla's new policy, this kind of testing and validation is essentially impossible: version 5 may contain critical security fixes not found in version 4, and with version 4 end-of-lifed, the only way to deploy those fixes is to upgrade to version 5. That may not be an issue this time around, but it's all but inevitable that the problem will crop up eventually.

Testing overhead

That makes things awkward for the companies who need to validate browser releases. Rolling out security updates with minimal testing is, in theory, generally pretty safe, because security updates are narrow in scope, and because the risk of the alternative—running a known-exploitable browser—is worse than the risk of something breaking. With those security updates now inextricably linked to other, nonsecurity updates, some enterprise users are expressing the fear that their task is now impossible. The other updates included with the security fixes mean that each release is so large that it must be tested thoroughly, but the rapid release schedule means there's no time to do so.

This has some corporate users of the browser feeling very unhappy. Though the release itself came as little surprise, the consequences it would have for version 4 were not generally understood until it was too late. They didn't realize that they would no longer have access to security fixes for Firefox 4, and now have to test all over again for Firefox 5. And to make matters worse, future updates will probably come out even more frequently; a six week cycleis the goal.

These enterprise customers are plainly unhappy, and some commentators are suggesting that Mozilla is alienating its enterprise customers and in effect signing its own death warrant.

Flawed assumptions

But is this really the right response to take? We're not so sure that it is.

Let's be clear: the enterprise has never been Mozilla's number one priority. If it were, thispair of bugs wouldn't still be open more than half a decade after they were first filed. For enterprises, deployment and patch management using MSIs and configuration control using GPOs, are bread-and-butter stuff. They're a hallmark of enterprise readiness. Internet Explorer—surely the king of enterprise browsers—has this kind of support in spades. Chrome, too has some amount of enterprise support.

I'm sure both of those bugs will be fixed eventually. The work will get done. But enterprise users should take note: they're not the priority, and never have been. This should not be regarded as surprising.

But what of those organizations that use Firefox anyway? How are they going to cope now that they will have to do all this extra testing?

The answer to that is: the same way they always have done. The reality is that Firefox minor updates have never been restricted to pure security fixes. If organizations thought that they could get away with performing only minor testing of the 18 minor updates that Firefox 3.6 has received in just 15 months, they were mistaken. Firefox minor releases have long contained stability and compatibility updates. Sometimes there are even feature changes: 3.6.4 introduced a new system whereby plugins were run in a separate process, and 3.6.9 introduced support for new countermeasures against a certain type of security flaw.

These kinds of changes could absolutely cause compatibility issues with business sites and applications. For businesses that needed to perform extensive validation of the browser before deploying it, then both of these updates would require new validation. And in both cases there was no way of avoiding the new features; there were few "pure security" updates made to 3.6. The implication that the new policy somehow changes something about the nature of Firefox updates—and hence the testing burden—just isn't true.

Combining security fixes with broader compatibility and stability fixes or new features is not unique to Firefox, either; Google does the same for Chrome, and even the latest security update to Internet Explorer 9 includes a minor nonsecurity update that resolves a bug with downloading files. The isolated pure security fix just isn't a feature of the Web browser landscape.

Meaningless numbers

Some have said that the testing problem is a result of Mozilla's decision to bump the major version number—with the implication that their company's testing procedures are driven not by an assessment of what's actually changed but by a mere version number, as if the major version increasing meant that there must be major changes.

Mozilla could have chosen a better mechanism to distinguish between versions than a major version number bump—for example, if they had used a date-based numbering scheme then it's likely that this (flawed) inference would no longer be made. But it didn't, and the result is that an increase of the major version number doesn't necessarily imply major changes under the hood.

Mozilla certainly isn't the first to do this. The next version of the Linux kernel will be version 3.0, from the current 2.6.39.2, but this major version update doesn't denote major changes. It might just as well have been version 2.6.40, or 2.8, or something else entirely; it was simply the preference of Linus Torvalds that the major version should, after many years, be increased.

Nor is Mozilla the first major open source project to use a time-based release model instead of a feature-driven one. The Ubuntu Linux distribution has made twice-annual releases, with major version numbers that increment accordingly, since its inception. The user community understands this and responds accordingly.

The corporate response to this change in numbering policy should be trivial: base testing on what has changed rather than what the number is. Any other policy has never been consistent with the way the browser is actually updated. At worst, the new update policy is simply highlighting flaws in existing corporate practices.

How was the breach caused, and how would IT locking down systems have prevented it? Was it a generic exploit, or something targeted at your company?

It was a targeted attack. As eye rolling as it may sound, I can't go into too many details - I love my job and they've asked us to this day not to discuss it in detail. We're a private company and we've been working very hard to restore client faith in us, and it's been a rough road in places. Suffice to say that yes, with the network and PC policies now in place the attack would not have been possible. After all, that's why they put some of those specific policies in place.

Which policy or policies do you believe is protecting you against future targeted attacks? How are you preventing arbitrary code execution and privilege escalation flaws, for example?

Quote:

I never made any claims about Firefox being OK before and not now, I do not work in IT infrastructure - my statements were just responding specifically to posts where people were saying that the releases were fine no matter a full version jump. An enterprise admin must treat FireFox's full version jump identically to any other software full version jump, and that translates to more time and paperwork.

But if the enterprise admin was doing their job properly, they had to do the same for Firefox's minor updates too.

Problem is, you have to prove that to the people that sit in the hot seat. You've got to prove that to the people who have to deal with lawsuits if something goes wrong.

I understand what you are trying to say, but I think you are wrong. Was the problem that someone was running unapproved software, specifically a newer version of existing and approved software? Or was it that they were doing something wrong, period? For example, if you are compromised when someone surfs a web site containing a FF5 attack vector, what caused the problem? Do you blame it on FF5, or on the person surfing the site containing the vector?

You have to remember that even in the most perfect conditions, testing of FF5 could only pull up known problems, not unknown problems. This means that even after approving the software, it could be vulnerable to something that was not identified as a problem to test. Same thing for IE9, IE8, FF4, Chrome Whatever, etc. You can only ever prove that known exploits are not exploitable, you can never prove that there are no possible exploits.

Therefore, one of the best ways to minimize the possibility of exploits is to look at behavior that leads to exploits and curtail it. You will spend far less time and money on security - and be more effective - if you lock down avenues of attack outright instead of attempting to test and certify all software as attack-proof.

This does not mean that new software should not be tested - FF5 itself may be fine, but due to a conflict with some other application, could cause anything from machines to fail to boot to some weird UI oddity when some other app runs. However, that has little to do with security testing and more to do with functionality and QA testing.

I understand what you are trying to say, but I think you are wrong. Was the problem that someone was running unapproved software, specifically a newer version of existing and approved software? Or was it that they were doing something wrong, period? For example, if you are compromised when someone surfs a web site containing a FF5 attack vector, what caused the problem? Do you blame it on FF5, or on the person surfing the site containing the vector?

You have to remember that even in the most perfect conditions, testing of FF5 could only pull up known problems, not unknown problems. This means that even after approving the software, it could be vulnerable to something that was not identified as a problem to test. Same thing for IE9, IE8, FF4, Chrome Whatever, etc. You can only ever prove that known exploits are not exploitable, you can never prove that there are no possible exploits.

Therefore, one of the best ways to minimize the possibility of exploits is to look at behavior that leads to exploits and curtail it. You will spend far less time and money on security - and be more effective - if you lock down avenues of attack outright instead of attempting to test and certify all software as attack-proof.

This does not mean that new software should not be tested - FF5 itself may be fine, but due to a conflict with some other application, could cause anything from machines to fail to boot to some weird UI oddity when some other app runs. However, that has little to do with security testing and more to do with functionality and QA testing.

My apologies, I think I gave the wrong impression - my two points were not directly linked, Firefox had nothing to do with what happened to us. My point there was simply that if you are jumping a full revision you have to make a stronger case to the person sitting in the hot seat. Their first instinct is to play it safe - which is completely understandable - and they're going to ask tougher questions for a full jump. In my mind, that's fair. By and large most non-OS software changes pretty heavily in a full version jump.

Which policy or policies do you believe is protecting you against future targeted attacks? How are you preventing arbitrary code execution and privilege escalation flaws, for example?

I'm going to botch the answer to your first question - Windows security administration was never a strong point for me, I use OS X and Debian at home and have always worked on *nix based systems in the office. We used to be able to install a pruned list of items via domain management policies, that was completely removed. We've switched to two-factor solutions across the board for both internal and external systems. They added secondary virus protection and two additional layers of malware protection (overkill there, perhaps). There's a lot of extended desktop monitoring that goes on, I have zero idea how that works. The list goes on, but again - Windows XP and Windows 7 security are fairly far outside my technical expertise. My overall point was simply that we used to have some freedom, we don't anymore, and I think we're safer for it despite the hassle. Sometimes those ridiculous seeming policies cover some very real dangers.

DrPizza wrote:

But if the enterprise admin was doing their job properly, they had to do the same for Firefox's minor updates too.

Out of genuine curiosity, have you worked at an enterprise level company before? Most of the policies look absolutely insane with looking in from the outside, but almost all of them are based in fact and experience. When it comes to upper management, they have the presumption - a fair one, I think - that a full version jump is inherently more dangerous than a dot revision. The simple fact it's a full version jump causes the question - "does it do anything new that we need? No? Then we wait." The IT techs themselves know and test and can present evidence all day long, but the natural inclination is for management to shy away from full versions. Is it a battle the techs can win? Easily. Is it a battle the techs want to fight every few months? The answer has already been posted here several times - no, no, and no. Not worth it. The folks that do the testing and make the arguments have networks to run, systems to administer, and lots of other things on their plates. They aren't going to want to take the time to make the extra pitch every time Mozilla decides to go up a version. The enterprise doesn't NEED Mozilla; they already have a web browser.

Of course, whether or not Mozilla needs the enterprise is a debatable question. I think they do, but that's only because it won't be possible to break the full MS stranglehold unless they make good gains with the enterprise. So - if we take my supposition as true - the enterprise doesn't need Mozilla, but Mozilla needs the enterprise. The version numbering change is completely arbitrary and serves no real point, and the enterprise gets careful around full version jumps from experience and strict policy adherence - policies that have legal repercussions. In my opinion Mozilla has made a needless decision that will cost them market share for many more years, and I think it's a bad move.

"It receives regular security bug fixes which will reduce the likelihood of getting owned repeatedly Sony-style. That reduces paperwork, lawsuits and embarrassing public disclosures pertaining to ownage and the associated posting of customer financial data to 4chan. And in the unlikely event such ownage and litigation does occur, it will show that we are not grossly fucking negligent."

I'm going to botch the answer to your first question - Windows security administration was never a strong point for me, I use OS X and Debian at home and have always worked on *nix based systems in the office. We used to be able to install a pruned list of items via domain management policies, that was completely removed. We've switched to two-factor solutions across the board for both internal and external systems. They added secondary virus protection and two additional layers of malware protection (overkill there, perhaps). There's a lot of extended desktop monitoring that goes on, I have zero idea how that works. The list goes on, but again - Windows XP and Windows 7 security are fairly far outside my technical expertise. My overall point was simply that we used to have some freedom, we don't anymore, and I think we're safer for it despite the hassle. Sometimes those ridiculous seeming policies cover some very real dangers.

In my view, from what we have seen of real-world targeted attacks (including the Aurora attacks against Google et al., and Stuxnet against Iran), not one of those measures will provide any effective counter against an adversary who wishes to break in to your specific organization. Nor, for that matter, would switching to an alternative operating system.

Quote:

Out of genuine curiosity, have you worked at an enterprise level company before? Most of the policies look absolutely insane with looking in from the outside, but almost all of them are based in fact and experience. When it comes to upper management, they have the presumption - a fair one, I think - that a full version jump is inherently more dangerous than a dot revision.

I don't actually think it's a fair one.

Quote:

The simple fact it's a full version jump causes the question - "does it do anything new that we need? No? Then we wait." The IT techs themselves know and test and can present evidence all day long, but the natural inclination is for management to shy away from full versions. Is it a battle the techs can win? Easily. Is it a battle the techs want to fight every few months? The answer has already been posted here several times - no, no, and no. Not worth it. The folks that do the testing and make the arguments have networks to run, systems to administer, and lots of other things on their plates. They aren't going to want to take the time to make the extra pitch every time Mozilla decides to go up a version. The enterprise doesn't NEED Mozilla; they already have a web browser.

Again: if the enterprise admins were doing their job properly they would have given minor point releases a full testing cycle because they were dangerous. The new policy only makes things were if you weren't testing Firefox properly in the first place.

Quote:

Of course, whether or not Mozilla needs the enterprise is a debatable question. I think they do, but that's only because it won't be possible to break the full MS stranglehold unless they make good gains with the enterprise. So - if we take my supposition as true - the enterprise doesn't need Mozilla, but Mozilla needs the enterprise. The version numbering change is completely arbitrary and serves no real point, and the enterprise gets careful around full version jumps from experience and strict policy adherence - policies that have legal repercussions. In my opinion Mozilla has made a needless decision that will cost them market share for many more years, and I think it's a bad move.

I don't think Mozilla needs the enterprise, I don't think Mozilla has ever catered to the enterprise, and if this leaves enterprise users running off to Internet Explorer, so be it. Most of them are already using Internet Explorer anyway.

In my view, from what we have seen of real-world targeted attacks (including the Aurora attacks against Google et al., and Stuxnet against Iran), not one of those measures will provide any effective counter against an adversary who wishes to break in to your specific organization. Nor, for that matter, would switching to an alternative operating system.

I'll grant you that yes - if someone qualified is truly determined then nothing will stop them. Not that many people are that qualified however, and it's THOSE people strict IT policies will stop. The policies in place at my job now would have stopped the attack cold - it was targeted and complex, but not necessarily sophisticated. Quite honestly when you're dealing with a business and revenue no matter how inconvenient the policy is if it will stop even just another 5% of the possible vectors then it's worth doing. You cover the bases you can with the tools you've got, to do otherwise is just careless.

Quote:

I don't actually think it's a fair one.

A difference of opinion there - I'll freely admit my perceptions are influenced heavily by my work history.

Quote:

Again: if the enterprise admins were doing their job properly they would have given minor point releases a full testing cycle because they were dangerous. The new policy only makes things were if you weren't testing Firefox properly in the first place.

Let's be clear here - I am not actually discussing the quality of the work done or the procedures necessary. I'm talking about the people they report to, the people who are tied to taking the blame for something going wrong. You have to pitch to them on their turf, because they are The Boss. If they say jumping from 1 to 2 is a bigger deal than 1 to 1.1, you have to work on those terms. When I say "bigger deal" I don't mean more testing, I mean more paperwork. More sign-off. More approval.

Quote:

I don't think Mozilla needs the enterprise, I don't think Mozilla has ever catered to the enterprise, and if this leaves enterprise users running off to Internet Explorer, so be it. Most of them are already using Internet Explorer anyway.

I agree, Mozilla has never catered to the enterprise. I don't think you have to cater to gain acceptance, and I don't think it would be catering to keep the prior versioning scheme versus the new one. Yes of course they are already using IE, Firefox wasn't truly strong (or even in existence) when these companies started using the web. The idea would be to win them over - even just through persistence and existence - and truly change those web usage numbers. Everyone - even the enterprise - will switch to better software if it's available, it just takes much more time and a lot more process-wise as you get bigger.

I'll grant you that yes - if someone qualified is truly determined then nothing will stop them. Not that many people are that qualified however, and it's THOSE people strict IT policies will stop. The policies in place at my job now would have stopped the attack cold - it was targeted and complex, but not necessarily sophisticated. Quite honestly when you're dealing with a business and revenue no matter how inconvenient the policy is if it will stop even just another 5% of the possible vectors then it's worth doing. You cover the bases you can with the tools you've got, to do otherwise is just careless.

Not if it costs more revenue than it can save, and you have to cover real bases, not imaginary ones. For example, a policy that lets people run stale browsers is a problem; they're more readily exploitable. But replacing that with a policy where you must run a specific browser is both overkill--"any up-to-date, current, patched browser" would do the job, and in fact, the single browser policy is probably less safe since it makes targeting an attack easier.

Quote:

Let's be clear here - I am not actually discussing the quality of the work done or the procedures necessary. I'm talking about the people they report to, the people who are tied to taking the blame for something going wrong. You have to pitch to them on their turf, because they are The Boss. If they say jumping from 1 to 2 is a bigger deal than 1 to 1.1, you have to work on those terms. When I say "bigger deal" I don't mean more testing, I mean more paperwork. More sign-off. More approval.

The management only has that perception because they have been allowed to form that perception. They need to be disabused of that faulty viewpoint.

Quote:

I agree, Mozilla has never catered to the enterprise. I don't think you have to cater to gain acceptance, and I don't think it would be catering to keep the prior versioning scheme versus the new one. Yes of course they are already using IE, Firefox wasn't truly strong (or even in existence) when these companies started using the web. The idea would be to win them over - even just through persistence and existence - and truly change those web usage numbers. Everyone - even the enterprise - will switch to better software if it's available, it just takes much more time and a lot more process-wise as you get bigger.

I don't think that's true. I think that there are plenty of people who don't even understand how or why there are better browsers than Internet Explorer 6, 7, or 8. That's one of the problems: they think their current browser works.

There is a way to stop that--stop making sites that are compatible with these old browsers--but it's painful to do if others don't follow suit. Google is starting to kill off Internet Explorer 7 support on its Web properties, and that's a good start. But even it won't do anything truly ballsy, like kill Internet Explorer 6 and 7 support on the main google.com homepage.

The management only has that perception because they have been allowed to form that perception. They need to be disabused of that faulty viewpoint.

I'm slightly confused as to why that viewpoint is considered faulty. It's only been the very recent rise of more web-centric apps and culture that's run contrary to what can be considered "classic" versioning. The software most business people are exposed to - at work and at home - runs off of the more classic view of versioning: full revisions are much bigger deals than dot revisions. I've seen a handful of things listed that do not follow that pattern, but there are so very, very many that do.

Almost any Adobe product - full revisions are "bigger"Oracle - full revisions are "bigger"MySQL - full revisions are "bigger"C# - full revisions are "bigger"PHP - full revisions are "bigger"Perl - full revisions are "bigger"MMOs - full revisions are "bigger"iTunes - full revisions are "bigger"OS X - full revisions are "bigger"Windows - full revisions (3.1, 95, 98, ME, 2k, XP, Vista, 7) are "bigger"Office - full revisions (4, 95, 97, 2000, XP, 2003, 2007) are "bigger"Firefox until this very change - full revisions were "bigger"

The list goes on and on. That's not to say that large changes don't come down the pipe in dot revisions - they certainly do - but it's considered almost standard industry practice to use a full revision jump as a flashy way to push "the next version" of a given product. That number change has been given significance over the years that honestly covers almost everyone - so why is it so weird that an IT director might draw an initial conclusion that Firefox 5 was a radical change of some sort over 4?

I'm not trying to be contrary, I'm genuinely puzzled as to why it should be odd to think a full version revision is a bigger deal. I mean, the whole idea of versioning started with "this is version 1, this is version 2, this is version 3" of physical objects long before software - and then someone at some time thought "hey, we're not really changing all that much so 2 -> 3 seems like overkill - how about 2.5?" Dot revisions then came to symbolize small changes, while major revisions were considered to be a large change of some sort.

Quote:

There is a way to stop that--stop making sites that are compatible with these old browsers--but it's painful to do if others don't follow suit. Google is starting to kill off Internet Explorer 7 support on its Web properties, and that's a good start. But even it won't do anything truly ballsy, like kill Internet Explorer 6 and 7 support on the main google.com homepage.

I'm not trying to be contrary, I'm genuinely puzzled as to why it should be odd to think a full version revision is a bigger deal.

The question is, how does it change your testing methodology? Do you perform different tests against Major releases than Minor or Point releases? You should not. Firefox 3.5.1 should have been subjected to the exact same testing as Firefox 3.5.0 and as much as Firefox 3.6.0. The process is simple - deploy image of base OS, install/upgrade app, run tests. The only part that changes is the "install/upgrade app" segment.

The idea that only a portion of the "run tests" step are applied on point releases is silly. This is why you get shit like a windows update deployed to the 100k seats at work fucking up 50k of them, because "it's just a patch." So? Because you treated it special, now 50% of our seats are screwed up. The cost of that is far greater than running the full test suite against every patch.

I'm slightly confused as to why that viewpoint is considered faulty. It's only been the very recent rise of more web-centric apps and culture that's run contrary to what can be considered "classic" versioning.

I don't think that's true at all. For example, between Windows NT 3.1, 3.5, 3.51, and 4, the version number changes don't meaningfully correspond with the risk of compatibility issues. Arguably also true with Windows NT 6.0 to 6.1. Nor do they with Linux 2.0, 2.2, 2.4, 2.6, 3.0; the minor version changes are all major, but the change from 2.6 to 3.0 is minor. Mac OS X hasn't ever received a major version increase, though it's certainly had major changes. .NET Framework 2.0 to 3.0 is a major change without corresponding major breaks in functionality. Internet Explorer 1 to 2 was a minor change. Exchange 6.0 (2000) to 6.5 (2003) was a major change.

Version numbers are driven by things like marketing and upgrade policies.

Except when they're not. The difference between Office 3 and Office 4 was the Word version (which jumped from 2.0 to 6.0). The difference between Office 4 and 4.2 was the Excel version (4.0 to 5.0). A major version upgrade of Word cause a major version bump of the Office version, but a major version upgrade of Excel didn't? And then Office 4.3, which had the same software versions as 4.2, but which was all 16-bit, rather than the mix of 32-bit and 16-bit in 4.2.

And since Office 95, the major versions have been kept in sync and updated together no matter what. Access 2000-2002-2003 (9.0, 10.0, 11.0) contain no major changes--they're all built on the same database engine--but receive major version number updates because their versions are tied in to the Office version.

Quote:

Firefox until this very change - full revisions were "bigger"

Was 2.0 to 3.0 really that much greater than 3.0 to 3.5?

Quote:

The list goes on and on. That's not to say that large changes don't come down the pipe in dot revisions - they certainly do - but it's considered almost standard industry practice to use a full revision jump as a flashy way to push "the next version" of a given product.

In commercial, paid software, I would say that the only rule is that a major version number change is almost invariably a paid update, whereas a minor version change is only sometimes a paid update.

Quote:

That number change has been given significance over the years that honestly covers almost everyone - so why is it so weird that an IT director might draw an initial conclusion that Firefox 5 was a radical change of some sort over 4?

Because there are historically so many counterexamples.

Quote:

I'm not trying to be contrary, I'm genuinely puzzled as to why it should be odd to think a full version revision is a bigger deal. I mean, the whole idea of versioning started with "this is version 1, this is version 2, this is version 3" of physical objects long before software - and then someone at some time thought "hey, we're not really changing all that much so 2 -> 3 seems like overkill - how about 2.5?" Dot revisions then came to symbolize small changes, while major revisions were considered to be a large change of some sort.

In a way, that's my point. And each of them do contain new features, whether or not you consider them to be big features are another story - that's subject to interpretation but the fact is there's a change of some sort.

OS X - That's a matter of perception. Since the name of the product itself is "10" I tend to drop it and consider the current version to be 6.8.

95-98-ME - greater hardware support, interface improvements, again - changes YOU may not consider to be big, but they're there. I've had to go back and use a 95 machine and a 98 machine, there's a noticeable difference. 2k to XP - um, if nothing else XP slapped a "pretty face" onto 2k. Did the interface completely reverse and suddenly work in a completely different manner? No, but there were substantial changes.

Office - I'll leave that one alone, I didn't start using it until 2000 - you reference primarily earlier versions. 2000, 03, and 07 had interface changes.

Linux kernel - I didn't talk about the kernel for 2 reasons: 1 - the change structure is definitely not linked to full revisions. 2 - I'd be amazed if you found an IT director for an enterprise company that cared in any way about Linux outside of niche or home usage, and doubly amazed if he/she knew the kernel inside and out.

Sure, some of the jumps between some of those products didn't go nearly as far as other jumps in the same line, but by and large - enough noticeable changes for the public at large, even if you don't agree.

In a way, that's my point. And each of them do contain new features, whether or not you consider them to be big features are another story - that's subject to interpretation but the fact is there's a change of some sort.

Sure, but minor releases also contain new features. Firefox patches contain new features. So do Windows service packs. etc.

Quote:

OS X - That's a matter of perception. Since the name of the product itself is "10" I tend to drop it and consider the current version to be 6.8.

The name of the product is roman numeral X. The version of the product is 10.6.

Quote:

95-98-ME - greater hardware support, interface improvements, again - changes YOU may not consider to be big, but they're there. I've had to go back and use a 95 machine and a 98 machine, there's a noticeable difference.

You miss the point: there was no major version change. They were all version 4.x.

Quote:

2k to XP - um, if nothing else XP slapped a "pretty face" onto 2k. Did the interface completely reverse and suddenly work in a completely different manner? No, but there were substantial changes.

But the major version stayed the same. They were both 5.x.

Quote:

Linux kernel - I didn't talk about the kernel for 2 reasons: 1 - the change structure is definitely not linked to full revisions. 2 - I'd be amazed if you found an IT director for an enterprise company that cared in any way about Linux outside of niche or home usage, and doubly amazed if he/she knew the kernel inside and out.

Given how widely used Linux is on the server, it seems very peculiar indeed to claim that people don't care about testing updates.

Quote:

Sure, some of the jumps between some of those products didn't go nearly as far as other jumps in the same line, but by and large - enough noticeable changes for the public at large, even if you don't agree.

The question is whether "major version number change" is synonymous with "major feature change". I don't think it ever has been.

[The question is, how does it change your testing methodology? Do you perform different tests against Major releases than Minor or Point releases? You should not. Firefox 3.5.1 should have been subjected to the exact same testing as Firefox 3.5.0 and as much as Firefox 3.6.0. The process is simple - deploy image of base OS, install/upgrade app, run tests. The only part that changes is the "install/upgrade app" segment.

The idea that only a portion of the "run tests" step are applied on point releases is silly. This is why you get shit like a windows update deployed to the 100k seats at work fucking up 50k of them, because "it's just a patch." So? Because you treated it special, now 50% of our seats are screwed up. The cost of that is far greater than running the full test suite against every patch.

Again - this has very little to do with the actual tests involved to make sure nothing breaks. Enterprise admins are (or at least should be) paranoid, testing everything they can. Full revisions can involve workflow changes and feature changes, something the admins don't test - that's for other departments. That's when the scope of installation widens, and that's what you've got to get past the people upstairs. If there are no workflow changes you have to demonstrate that. That's one of the primary reasons enterprise software does NOT make large changes in dot revisions - it's a nice little informal agreement to indicate when it's time to pull the entire company into testing and evaluating every aspect of the upcoming install. I've been part of these upgrades in the past, and it's an entirely different animal than getting a patch pushed out.

OS X - That's a matter of perception. Since the name of the product itself is "10" I tend to drop it and consider the current version to be 6.8.

95-98-ME - greater hardware support, interface improvements, again - changes YOU may not consider to be big, but they're there. I've had to go back and use a 95 machine and a 98 machine, there's a noticeable difference. 2k to XP - um, if nothing else XP slapped a "pretty face" onto 2k. Did the interface completely reverse and suddenly work in a completely different manner? No, but there were substantial changes.

The internal major version number didn't change in those cases. Windows 7 still reports "version 6.1.7600" for instance.

And if you can arbitrarily drop the 10. from Mac OS, why can't you put an imaginary 1. in front of Firefox's new version numbers and stop worrying about frequent "major" updates harming its enterpriseyness?

Given how widely used Linux is on the server, it seems very peculiar indeed to claim that people don't care about testing updates.

I was talking about the director caring in general, that has nothing to do with testing. It was also partially sarcasm about the suits, sorry that fell flat.

Quote:

The question is whether "major version number change" is synonymous with "major feature change". I don't think it ever has been.

*sigh* To YOU. You don't think so. Quite a few other people do, including a number of earlier replies to this thread. I'll concede the actual version numbering on the particular items we've been discussing at the moment, OS changes can be badgered back and forth enough to where I should have avoided them just to keep out of a quagmire that misses the point. The rest of the examples still stand, and if we want to go back and forth I can keep providing additional examples.

And if you can arbitrarily drop the 10. from Mac OS, why can't you put an imaginary 1. in front of Firefox's new version numbers and stop worrying about frequent "major" updates harming its enterpriseyness?

I owned up to that wonkiness. :) Let's chalk that up to the Mac lover in me and roll our eyes together.

*sigh* To YOU. You don't think so. Quite a few other people do, including a number of earlier replies to this thread. I'll concede the actual version numbering on the particular items we've been discussing at the moment, OS changes can be badgered back and forth enough to where I should have avoided them just to keep out of a quagmire that misses the point. The rest of the examples still stand, and if we want to go back and forth I can keep providing additional examples.

And I can keep providing examples where they don't. Which is why I say it's never been a reasonable policy to equate the two. People may do it, but people do lots of stupid things. Even if many programs do follow that rule, there have always been far too many exceptions to base serious decisions on the version number.

Again: if the enterprise admins were doing their job properly they would have given minor point releases a full testing cycle because they were dangerous. The new policy only makes things were if you weren't testing Firefox properly in the first place.

Thus preventing the Catch-22 for any organization that can't fully regression test a new Firefox release and its security updates: either they release software that's not fully validated, or they release software for which no security updates will be provided any longer.

It's clear that a browser vendor that wants to compete in the enterprise space must support more than one major release train. It's also clear that by choosing to chase Chrome's tail, Mozilla has chosen not to provide that ongoing support. Is it reasonable that any size of enterprise should need fully automated regression tests just to deploy any software?

How can any enterprise run Chrome or Chromium, knowing that updates could break functionality but not being able to forgo fixes, excepting the organization that creates Chrome?

Again: if the enterprise admins were doing their job properly they would have given minor point releases a full testing cycle because they were dangerous. The new policy only makes things were if you weren't testing Firefox properly in the first place.

Thus preventing the Catch-22 for any organization that can't fully regression test a new Firefox release and its security updates: either they release software that's not fully validated, or they release software for which no security updates will be provided any longer.

Even Microsoft includes non-security fixes in their security updates. Of Microsoft, Mozilla, Google, and Apple, Microsoft is clearly the most conservative of the bunch; their updates are the least likely to break something or cause other problems. But they still contain non-security fixes.

Quote:

It's clear that a browser vendor that wants to compete in the enterprise space must support more than one major release train. It's also clear that by choosing to chase Chrome's tail, Mozilla has chosen not to provide that ongoing support. Is it reasonable that any size of enterprise should need fully automated regression tests just to deploy any software?

It's also clear that "supporting more than one major release" is doing Internet Explorer no favours, as its market share continues to head downwards.

Quote:

How can any enterprise run Chrome or Chromium, knowing that updates could break functionality but not being able to forgo fixes, excepting the organization that creates Chrome?

By using it as a Web browser, used to access the public Web, and not depending on it for access to mission-critical LOB applications.

Full revisions can involve workflow changes and feature changes, something the admins don't test - that's for other departments. That's when the scope of installation widens, and that's what you've got to get past the people upstairs.

I am not seeing how your test for FF would change. You are most likely checking how it works besides other applications for conflicts, and checking how web applications work within it. That they changed a keyboard shortcut makes no difference for the testing - it either conflicts or it does not. How exactly is the scope of installation widening?

Quote:

Thus preventing the Catch-22 for any organization that can't fully regression test a new Firefox release and its security updates: either they release software that's not fully validated, or they release software for which no security updates will be provided any longer.

Security updates get full regression testing, too, so it is no different. If it were not for security updates getting this testing, no-one would ever be more than a few hours out of date, but what do you think holds up companies from installing ultra-super-important patches for insane lengths of time? Lack of regression testing of security updates leads to problem deployments, it is never recommended.

The version number is irrelevant. They could (if they wanted) number it version 6,000 and only change the icon. Nobody should take that number as any indication of the volume or significance of changes in the code.

More to the point though, if companies would construct their web apps to established standards (instead of relying on security holes and unsupported workarounds) they would have far fewer issues with new FF releases.

This article completely ignore the notification and auto-updating issues. Yes, people know Mozilla is going to pursue an aggressive update schedule. But the lack of notification regarding this release AND that it was a significant release auto-applied is absolutely unacceptable to any serious organization that needs a hint of predictability. Further, it's unacceptable to consumers as well as a general principle. Yes, I, personally, as a consumer do accept the risks of being on Mozilla's beta program on one of my PCs and I am pretty okay with what they release and I let it flow...but that was my choice and I knew the risks. People should have full control here, and Mozilla performed the unthinkable: an automatic update crammed down PCs without choice or notice. The article ignores they did give a cursory apology, at least, which means they do understand and accept, however minimally, they made some mistake here.