Is the Thunderbird Rapid Release Strategy working to the good of users?

[davidsk]

If you don't live under a rock, you're probably aware of the problems with Thunderbird version 102. In fairness, the release notes emphasize that it isn't ready yet to announce as an upgrade. I respect that, but users hear of an  upgrade and seize upon it, only to then complain of the problems. And they are right; there are many, many bugs in 102, but with patience, I have had no problems. But I'm straying from the topic. My concern is that it appears that version 102 was rushed out prematurely because it is on a rapid release schedule. The perception it gives is that the developers saw the release date and rolled out the code as it stood on that date. True or not, that's the impression because the bugs list seems infinite. Otherwise, there seems no explanation on why that release seemed so buggy.

My suggestion is to the developers to stand down for a day or two to review all that caused the problems and to rethink the purpose of a rapid release strategy. Users would rather see new features delayed than have them delivered earlier, but with accompanying bugs to deal with. How do we get this to the developers to revisit how they develop, test, and (we hope) regression test new releases?  

[wsm]

It is true that we need to stay in line as much as possible with the Firefox release schedule.  And we are still tied to that schedule.

However, in the last year we've made great strides in the release process compared to version 102, so that ESR releases starting with version 140 are much more reliable and stable.  This is due to a combination of factors, for example monthly releases, more feedback from beta users, a QA group, closer monitoring of bug reports, a full time release manager, and more.  Also important, there is more collaboration with contributors and staff in areas of support, coding, and release.  Everyone working together makes a big difference.