Traditionally the developers tool of choice, Firefox are making some pretty cumbersome decisions which can adversly affect project development. With IT managers berating the impact on rapid releases in corporates met with a near who cares attitude from Mozilla, there are also massive implications on developers, either freelance or agency based.
Faster release cycle
This, combined with automatic updates, will make it difficult to support Firefox in projects.
If an automatic update rolls out during project development, and the developer hasn't disabled automatic updates, the developer tools and add-ons they rely on can stop working. This is because a fast release cycle is hard for what are essentially side projects to be tested and updated so freqently.
Firebug is the most common add-on to fail (at least initially) which can adversly affect development time.
General agency browser policies give version numbers because this both aids testing and clearly defines what the project budget has been spent on. Sure, as vendor support for an older version ends, this should be updated with a cost to cover any changes necessary.
If a client has paid for a site to work in Firefox 5 the site should work in Firefox 5. Giving support to Firefox (latest) means that agencies or developers will be liable to fix any potential problems that can arise from a later version.
Removal of version numbers
This makes it hard to support user issues with sites to replicate bugs if you can't easily find the version number.
The version number changes, as with Chrome, make a mockery of what is seen as a software standard. Firefox 6 feels more like a Firefox 5.1 as the changes are not so vast to warrent a full version number change.
Can we be confident the changes made have been fully tested? When new versions were release every year or so you'd have a good idea that some significant time has been spent implementing and testing new features. With three versions already out this year, and the latest in under two months, how much was changed and how much time went into each QA cycle?
So what to do?
You could always drop support for the fast moving Chrome and Firefox which, although a little extreme, will highlight to clients the potential instability such rapid release cycles bring.
It's best to avoid future suprises by supporting the lastest and greatest version of each browser. Instead use a combination of instinct, visitor stats across your sites and keep your browser matrix concise and frequently up to date.
Be frank with clients up front and let them know the implications of testing and development time to change support during a project. Most long term projects will include a retainer and this can be included as part of it. Short lived projects will tend to finish before a new version is out and has significant visitor use.
With your development teams make sure everyone has turned off automatic updates and update your browsers as a team and between projects (so as to avoid any unexpected suprises on the morning of your deployment). Look into using other browsers for your main development - Opera haven't gone for the multi release and have some decent tools. Even the debugger in IE9 isn't bad.