Beyond Firefox 4.0: Handling an accelerated development cycle [LWN.net]

Beyond Firefox 4.0: Handling an accelerated development cycle

Posted Mar 12, 2011 13:38 UTC (Sat) by eduard.munteanu (guest, #66641)
Parent article: Beyond Firefox 4.0: Handling an accelerated development cycle

I really hope Firefox people will reconsider this proposed versioning system. It's seriously reducing information related to stability and major architectural changes. And for what? So that Firefox plays catch-up with other browsers? It certainly doesn't mean more work is being put into it and it certainly doesn't help setting realistic goals.

It's really good to see a move towards releasing more often, but messing up with the versioning scheme in this way is bad. Other projects are able to keep up with similar goals without resorting to such tricks. Just release when something gets done, not just because a few months have passed.

Maybe the problem lies in merging too much too soon? Maybe those features should stay out of the main tree until most issues/bugs have been ironed out? I don't know, I'm not involved in Firefox development, but perhaps there are better solutions to this problem.

(Log in to post comments)

Beyond Firefox 4.0: Handling an accelerated development cycle

Posted Mar 21, 2011 5:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

what stability information do you think is being lost?

it sounds like you are under the impression that the developers introduce new stuff for a .0 release and then only fix bugs for .1, .2, etc.

the sad reality is that they are introducing new stuff for every release, so there are no releases that are as stable as you are thinking they are.

on the other hand, as the kernel development has shown, you can get good results both for stability and for rapid introduction of new features with a rapid release cycle.

but when you do this sort of rapid release cycle, you really don't have a reason to believe that any release is significantly better than any other (without testing). how good the releases are will depend a lot on the testing that gets done on the patches before they are put in upstream. it may be that there is reason for a series of bugfix-only branches (like the kernel -stable series), but we'll have to see at what rate new bugs are introduced, and who is willing to backport the bugs for how long.