Actually, whenever I’m talking with other Mac users, we just use the numbers and pretty much ignore the cats.
Does Firefox check that or does the extension check Firefox’s version? I think it’s the latter.
Either way, yes there are problems with shifting to a rapid release schedule and in the past most software assumed a version number change meant “big” changes and a release number change was bug fixes and minor functionality.
But the issue really is not how the identifier is formatted, but rather how can new functionality and bug fixes be released rapidly with minimal disruption. From my perspective the browser devs need to find a way to change functionality and introduce new functionality in a way that is compatible with previous iterations.
When I’ve dealt with this type of problem in the past, we would typically either preserve the old API and map to new internal processing, or add additional portions/extensions to the API that could be optionally used etc.
Absolutely. For people who want stable systems, you generally don’t want to get the first major revision. It’s better to stick with version 3.6 for example than to switch to 4.0. When 4.2 comes out, then you upgrade. That way you are much less likely to run into major problems.
With the new system, you can’t tell if they’ve made a major change (with much more risk of breaking something) or if they’ve just changed an icon somewhere.
Of course, with the new system they just expect you to constantly update anyway. And with version numbers changing so rapidly, extensions that check the version number are breaking left right and sideways. And this is supposed to be better somehow?
The traditional accepted way of versioning (although more often observed in the breach) is major.minor.build.
1.0.0 -> 1.0.1 means updates for performance, bugs or security fixes but no outward changes in the behavior of the software.
1.0.1 -> 1.1.0 means new features were added but software remains backwards compatible with the 1.0.x branch.
1.1.0 -> 2.0.0 means no guarantees about compatibility and possible ground up rewrites of features.
Firefox has shifted to a faster release schedule, not only for marketing reasons, but also because they changed the way their internal organization ships. Instead of big bang releases once every 2 years, they want to ship a new version once every couple of weeks. This means features get into the hands of users faster but at the expense of continuity.
Several enterprises have already rebelled at this due to not having a stable platform to target which has lead to “LTE” releases which receive bug but not feature updates until the next LTE.
A feature designed by Microsoft corporate office – horrors!
Just imagine:
If Microsoft designed your hooker:
- each new release comes in dozens of hooker versions, from Starter to Home Premium to Professional or even Ultimate.
- the price increases on each new hooker.
- new hooker versions have body orifices incompatible with previous equipment.
etc.
And using them dramatically increases your chance of infection.
You know what? Forget the browser!
Firefox main versions are mostly fairly large, they’re not just an icon anyway. They also has minor version numbers, but they seem to be only for big bugs and rarely go past .01 or .02. Since 10.0, add-ons are supposed to automatically be compatible with new Firefox versions.
Yes, but when you go to the Apple store, the box for the upgrade has the cat on the cover. It’s the same with their hardware - finding the actual model number of an iPod/iPhone/iPad/Laptop is far more difficult than it should be. It’s usually laser-etched in tiny script like they are embarrassed by anything as gauche as an identifiable as a specific identity number for a specific piece of hardware.
I don’t know about the first three, but on a Laptop you just check under “About this Mac”/“more Info” on the top right of the screen
Are you sure?
My understanding of the change was that now the default assumption by Firefox is that add-ons will work, so they are just not disabled when the version is updated. Previously, they were disabled, and the user had to re-install/re-activate them.
Apparently they feel that most add-on authors now follow coding guidelines, so their add-ons will be compatible with a new release. But I think it’s still just an assumption; obviously Firefox can’t actually test all the add-ons that are available.
The thing that is so Ironic is that Firefox 12 and Firefox 4 are largely the same browser. They look the same, They act the same. And if trend from Chrome continues, that will be the case for a long, long time.
Then again, if Mozilla actually thought that Firefox’s low version numbers were keeping people from adopting or staying with the browser, then I’d say they were already sunk. I wish they’d stop trying to be everyone’s browser and stick with what they are supposed to be: the one that gives the user the most choice.
The goal with rapid releases is to get functionality out as quickly as possible without having to wait until X number of other items are completed also and releasing everything at the same time.
I’m pretty sure the goal wasn’t to just match Chrome’s version numbering system independent of the release of functionality issue.
(top left)
And when I do that, it tells me
Mac OS X
Version 10.4.11
(Software Update…)
Processor Dual 867 MHz PowerPC G4
1 MB L3 cache per processor
Memory 512 MB DDR SDRAM
Startup Disk Macintosh HD
(More Info…)
No mention of “Tiger” (I think that’s the right cat) anywhere there, nor under the More Info button.