On 08/01/2011 12:47 PM, Bill Davidsen wrote: > Jens Hatlak wrote: >> hawker wrote: >>> That said 2.2 has had the most regression bugs, >>> lost features and new bugs of any version I have seen since before 1.0. >>> I hope this new "rapid" release is not causing SM quality to suffer and >>> this is just a bad build that we will get past. What is the feeling of >>> the development team on this build or is this just the build where the >>> issues have finally gotten to areas that affect me? >> >> Yes, SM 2.2 contained more issues than usual. We tried to fix some >> issues 2.1 had but others popped up, especially in MailNews and the >> address book (some things were not fixed entirely, and changes >> Thunderbird developers made to shared MailNews code were not fixed on >> our end fast enough). >> >> 2.2 was the first release after we switched to the rapid release >> process, and in this case we had even fewer time than the usual 6-18 >> weeks that the process dictates because 2.1 had already been delayed. >> >> Also there are some problems that appear due to the all-volunteer nature >> of the project. There are only very few developers in the first place, >> reviews (which are mandatory for any code change) take quite long. In >> former times (before 2.2) we had many months time to fix things and >> release "when it's ready". Now we're pretty much date-driven. This >> requires paying more attention to regressions by everyone involved. >> There is a lesson to be learned there, and I think 2.3 will be better >> overall [even though I personally would have voted to respin 2.3b1 so >> that we don't release a beta with major issues that are already known to >> be fixed for 2.3]. >> >> Personally I'm not a huge fan of the rapid, date-driven release process >> either but we have little choice: Security fixes (which usually affect >> Gecko or other code shared with Firefox) are only fixed on the latest >> stable Mozilla platform version so we cannot skip one without exposing >> our users to security risks. This is (very) unfortunate but nothing we >> can influence, so there is no point in complaining about it. We have to >> make the best out of it. >> > So does the API of Gecko change with every release? I would think you would > be > calling for services and fixes would be in the service. Does it really change > so > much that you can't link against the current code? > > I like the Linux model, where stability fixes are provided against recent > releases, so people don't have to constantly upgrade. I would think that was > a > problem for Mozilla and corporate users as well, and a reason to provide bug > fix > only support for 90 days or six months, or something reasonable. No > corporation > I have supported would update softweare every six weeks, other than to apply > patches. >
Might be an interesting read: <http://news.cnet.com/8301-30685_3-20074590-264/rapid-release-firefox-meets-corporate-backlash/> _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
