Writing software is actually quite easy. Writing good software is relatively harder, but still easy. Writing software to a programmer is like painting to a painter. Shipping software is an incredibly complicated task. It’s like getting a stadium full of babies to all have clean diapers at the same time with only one or two people to do the work. As soon as you fix one thing, you discover more crap. The process stinks and you’ll never reach the end. Those who do it either by printing a CD, uploading a binary, or pushing out changes to a tier of web servers know what I’m talking about.
It’s easy to write code to do things. It’s harder to build a product. It’s harder still to actually draw a line in the sand and decide when you’re “done”. The truth is all software ships with bugs. Someone who tells you otherwise is an idiot. They almost certainly aren’t all discovered, very likely some will be, but they absolutely exist. The general consensus is you want no glaring bugs and you don’t want big bugs in common use cases. Obscure use cases will always be more buggy. That’s the nature of the beast.
Knowing this, it’s easy to understand that changing release cycles will be an arduous process with lots of details to think about. Not everything is quantitative or can be reduced to a math equation. How long is it worth waiting for a feature? Is the shiny button worth 3 days? 3 weeks? 3 months? Indefinite hold? Will it even work as we think? What bugs will it introduce? How long to deal with those? Not an easy decision. Even harder to reach a consensus on. The only thing certain is the lack of a decision will guarantee a failure to launch.
The Firefox Version Problem
Firefox is now a 6 week release cycle. This means features get out the door soon after they are fully baked. That’s a very good thing. That means adoption of modern technologies and the latest in security is out there quickly. We all benefit from that.
The downside however is that upgrades are disruptive. They can break compatibility, and they require extensive testing in large deployments (big companies, educational institutions). That can be expensive and time consuming if you’re impacted.
The other side of this is version numbers get blurred. 4.0, 5.0, 6.0… “WTF is the difference” most users would think given it looks largely the same. But is it really 4.0.1, 4.0.2, 4.0.3? As a web developer, what versions are you supporting? This is now much more complicated (don’t even get me started in testing).
Stable vs. Slipstream
My modest proposal is a Stable/Slipstream (I prefer “slipstream” vs. “bleeding edge”) model. For example:
Firefox 7.0 ships in 6 weeks, September 27 as of this blog post. From then on, every 6 weeks a new release ships and would become 7.1, 7.2, 7.3 etc. For users, it’s just auto-updates every so often. These intermediate releases are disposable as the users are on the slipstream. They rapidly update. A matter of weeks after the release the previous one is unsupported. Previous releases are just a rumor, recognizable only as deja vu and dismissed just as quickly1. They are oblivious to the concept of “versions” for the most part. After several release cycles (9-12 months), this becomes “stable” at 7.x. The next day 8.x starts and the process starts over.
From then on (I’d propose 12 months) only security fixes will be provided to 7.x. For large deployments who need to do extensive QA, they adopt the stable branch once a year on a predictable schedule and stick to it. For the vast majority of the internet, they adopt the slipstream (default) and get the latest release every 6 weeks. The stable branch is only around for a limited period of time before it moves to the next version. That last release cycle may be a bit more modest and lower risk than the previous ones.
The end result is that nobody cares about a release older than 12 months. Generally speaking only 2 matter. Slipstreamed users are updating rapidly (and will likely update even more rapidly as the process improves). Stable users have 12 months to hop to the next lily pad. This goes for IT, web developers, add-on developers, browser developers.
In the long term (next few years), I think web applications will become more agile and less rigid. Part of what things like HTML5 provide is a more standardized and less hacky way of doing things. That means less compatibility issues with untested browsers. As those older applications are phased out, the test cycles for large deployments will decrease. Ideally some will eventually just migrate away from “stable”.
Yes, version numbers still exist, but for most users they don’t mean terribly much unless they have a problem or need to verify compatibility with something. In which case, the major release number is likely the important one. They are still a necessary evil, and users do need to know how to get it, even if they don’t need to know it offhand. Browser version number is pretty much the first step of any diagnostics for a web application as it’s the ultimate variable.
Just my thoughts on the last several weeks of debate.
15 replies on “On Firefox Versioning”
You lost me in the version number thing. Basically you are proposing to have a version 7.0 as stable version and will be supported for 12 months. And the rest of us will be on 6 weeks release schedule with version number 7.1, 7.2 etc
This will be good for cooperate customers.
But How do you ensure addon works for all 7.x?
The only QA anyone should be doing is making sure their intranet apps are W3C compatible, and then they will work on Chrome, Firefox, even Safari, any current or future version.
Firefox used to have versions supported for a long time with security, and that combined with the limited resources of Mozilla development led to the disaster of it taking nearly 3 years for Firefox 4 to be released, leading to the beginning of the trend of Firefox market share plummeting.
The only place where a LTS version of Firefox might exist is on Linux, and it will NOT be done with any official Mozilla support. There are Linux people, probably Debian people, who will probably be willing to put in the effort of backporting security fixes to allow a version to be secure for a long period – they do it for most other Linux software. Kooky, but they are weird guys so you expect it.
Maybe the developers want me to have the latest version, but it’s not always what I want, and above all, whether latest version or not, I want to know what I’ve actually got. From my pov, this will ensure that I never go back to Firefox from Avant browser (after abandoning it a while back because of the memory leaks and denials that there was a problem.)
My thoughts are along those lines too. The only thing I’ll change is the “major” version number. Instead of 7,8,9, I think using years makes it much easier to communicate.
The first release we do in 2012 (should be mid february if I’m not mistaken) is called 2012.1. This is a 6-week auto-updating build. At the same time, we release 2012.0, the 1-year long supported version. It is exactly the same as 2012.1, except for the updating mechanism. The next 6-week releases are 2012.1, 2012.2 etc. And the security releases of 2012.0 are 2012.0.1, 2012.0.2.
And in 2013, 2012.10 updates to 2013.1 while 2012.0.x updates to 2013.0.
It seems the same as what you are proposing but the version number carries the information.
I sure agree with this stable / slipstream model (or LTS / rolling release). A lot of users would want to stay on a stable version, especially as long as the addon breakage issue hasn’t been solved. And for the sake of the Mozilla ecosystem (aka XUL platform), stable branches are a necessary evil. I do realize that a stable branch has a cost, though.
The version numbering makes sense — many contributors have proposed a similar scheme (either like yours or like the one Anthony suggests). I don’t understand why we’re still making the community mad with the (now meaningless) version numbering. Like Gerv said:
@DaveB: It took roughly a year and a half to release Firefox 4 – which is bad enough but nowhere near what you describe. Fact is, both Firefox 3.5 and 3.6 were major releases but they weren’t marketed as such.
@Robert: Given that Firefox 9 nightlies are already out there, “stabilizing” the version numbers on 7.x won’t work any more. Either way, I can rather imagine Anthony’s suggestion being implemented because is keeps predicable version numbers that are also understandable to users (e.g. they actually communicate that releases are schedule-based).
As to the LTS version – DaveB might be right and Mozilla simply doesn’t have the resources for that. They have to compete with Google which has far more people on the browser and doesn’t spend any effort on LTS versions.
There is another reason why we need stable releases, my mother who is 72 is not computer savvy and just does not know how to use computers, it takes her months to get used to the slightest UI changes on her computer and she certainly can’t follow UI and features changes in a browser every 6 weeks, a yearly LTS is OK, I can spend a few hours with her training her to use the new UI and features with the new release, I just can’t do that every 6 weeks, that’s wasting both of my and her time.
@DaveB: Good luck forward testing like that. You’re talking about IT staff, not web developers testing third party products. Not to mention, “W3C compatible” is meaningless as specs are now “living” and “fluid”.
@Anthony Ricaud: It’s pretty much the same thing, just a different numbering scheme. My main point is the idea of a long term build being the end result for those who need long term stability for deployments.
@Pascal Chevrel: Same goes for enterprise. Not every employee really understands computers. Some are barely computer literate. Changing things on them every 6 weeks is brutal on productivity. Not every company will stand for it. Just because their computer skills are lacking doesn’t mean they aren’t otherwise top notch employees. Computers don’t run every part of every business, at least not yet.
Basically it’s the same LTS idea which I tried to push more than one month ago. But the more, the merrier. Just join the entreprise support group to try to make it happen, maybe by committing to provide actual resources.
@Pascal, @Robert : I’m not so sure. It may be easier for a user to adapt to small, incremental, changes rather than receiving a new version that’s completely different.
What really upset my 70 mum recently was more TB 5 crashing systematically at startup, due to bug 662634 that is fixed in TB 6 but not ported to TB 5 and no respawn of TB 5 was done.
At the time she installed TB5, the fix had already been committed, it just was not ported to TB5.
I like it, a lot.
If anything, to bring some peace back to enterprise, users, add-on developers, and especially to stop the mass exodus of those in enterprise, add-on developers, users, and Mozilla contributors.
Someone/something has to stop the bleeding.
Of course it will be critiqued, sometimes harshly, perhaps tweaked, but it’s a good, reasonable, sane, solution.
As far as there not being enough resources, bull. Do more hiring, most importantly from within the community, promote contributors, find a damn way, because it would benefit everyone and it’s the right thing to do.
The only thing that I would never want, and would disable, is silent automatic updates.
“find a **** way”
That was d_a -mn
This sounds sane.
We’re dying in the business/office sector.
In business they talk about how much more it costs to make a new customer than to keep one, so by all means keep what you got. With browsers the story gets more complex. Most people are not early adopters or fickle by using whatever is fastest right now. It takes a long time to change their patterns. And when they do, they’re going to keep it for a long time. They’ve gotten comfortable with it.
My point is that we’ve got to stem the flow ASAP because further losses won’t be regained any time soon, if ever.
I had an idea that I wrote in a comment here: http://weblogs.mozillazine.org.....isson.html (I can’t link directly to comments there, so it was the comment by “Jake” on July 26, 2011 – at the time of me writing this comment, it is 3rd from the bottom).
Basically, I’m saying the same thing (almost). Here is a quote of my comment:
I very much like the idea here but wanted to chime in that I also really like the concept of moving to yearly version numbers.
I have thought about this quite a lot over the years and the best example of another industry that has to regularly release new, fairly incremental, iterations of their products is the automotive industry. They don’t have the Honda Accord 35; its’ the 2011 Honda Accord.
More importantly, perhaps, it’s not branded as the 2011, it’s just a Honda Accord and the model year is only used when it’s relevant like when there is a problem. Similarly, most users don’t need to know what version they are using but it certainly matters in certain situations.
Nice article. Like it.
From my perspective, this happened: I got all addons working and the configuration tuned for FF 3.6. Then FF 4 came out and I figured, best wait and see. Wait for security fixes, wait to see if I like the looks, wait for the addon coders to adapt. Then 5, 6, and now 7 came out. And I went through the trouble of looking into this fast versioning. Its in the common users mind: major release numbers equal major changes. Most users are conservative. No matter that the market abuses the people who always want the best, newest and fastest only to advertise their product. I am a conservative user. I would like to see the major release numbers reflect changes that will break the addons and my settings. And number.x relese steps to be associated with releases that do not break my addons and my config. I dont trust Google, I dont want to pay for Apple and I dont want to be pushed around by Microsoft into using only their technology. I need an independent browser. Opera didnt work, for some very simple technical reasons. Firefox is what I am looking at and I agree with a lot of the comments made here.