That kind of thing shouldn't be left up to either the user or developer, though... the design should be better so that extensions don't break with an upgraded version. I assume things are going to have to be changed, because people are going to be annoyed quick if their extensions break four times a year.
Absolutely. They are bound to change. One just can't have a version-bound extension framework with rapid release cycles. Especially when FF extension base is so vast and varied.
One thing I've noticed is that neither Mozilla or Google care much about version numbers though. Google has never had the version number even appear on its Chrome homepage, and I noticed last night that Mozilla has opted to do the same. Neither of them want the regular user to care about version numbers anymore, it seems, but it begs the question, why the focus on major increments?
Personally I think it's marketing cave-in to user demands.
I've been noting an increase in users demands for faster and more updates. The rapid release cycle of some popular projects (including Chrome) has given the impression to some people that they get faster and more updates to their software than with more traditional development methods. On the other hand they associate this type of release cycles to faster bug resolution.
Under most cases, they couldn't be further from the truth. Programmers don't just work faster under "release early" models. What happens is that releases are essentially partitioned into smaller parts and those parts make their way into the public. All things being equal, at the end of the day, you get the same number of fixes and the same number of new functionality. Only one gives them incrementally, while the other lumps everything into a major/minor release.
The RERO (Release Early and Release Often) methodology has, in my opinion, been taken entirely
out of the original context by too many a developer team, through the years. Moreover, it isn't necessarily something one should wish applied to all sorts of projects or for all sorts of users (the corporate market segment is an example of one market that isn't sympathetic at all to RERO). But more damaging, this methodology is today being brandished more and more as a marketing tool that tries to give users the idea that they get more and better in less time. And users easily buy that notion, being that
consumer greed (and a certain dose of naiveté, I'm afraid) is unfortunately widespread in our societies.
Truth however is that you get essentially the same during the same period of time. And it's usually only after a lengthy period of time that you can eventually know if you got any better. The fact is that RERO removes testing time. The burden is put almost entirely on the shoulders of beta testers and final users (being that beta testing cycles are them too shortened). So the possibility of introducing more bugs into public releases is there, is very real, and is very common.
Now, if you are coding an API, some sort of programming framework, or an operating system kernel, or a MMO game, or any other type of project where there is a tangible, very real, benefit to rapid release cycles that's when you want to do it. Similarly if you have a small, dedicated, competent and well organized team of developers. And that is what Eric S. Raymond was referring to when he first coined it. He never meant to say this is the best way to do it. He was saying this was the best way to do it if you are doing anything that can draw some real benefit from it and if you meet the conditions to do it.
And the most annoying bit about all this marketing hype response to consumer demands, is that in fact the full phrase is
"Release early. Release often. And listen to your customers." You notice the "And". It's because the former doesn't work at all if you don't do the latter. That's in fact the whole point of doing it. And has Mozilla been known for listening to its user base?...
As long as FF takes longer to start then my desktop takes to boot, FF is a nono for me anyway... I use Chrome, and won't turn back to FF anytime soon
That's the type of argument that is at the core of all that is wrong with software today. That was never a reason why FF bothered me and I cannot understand why people get so worked up about software taking even 10 seconds to load up.
If we settled down a bit, took a deep breath, and stopped wanting to be everywhere, every time, and as fast as possible, maybe just maybe we wouldn't put the wrong pressure on development teams to solve non-issues and the software we use today would have less bugs, be better constructed and have more functionality.
Just saying.
