112
edits
Thunderbird/July2012AndBeyond: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 70: | Line 70: | ||
JBPiacentino: This means that Thunderbird and Thunderbird ESR will use Gecko 17, which will be updated for security and stability avery 6 weeks, for the whole 54 weeks ESR cycle duration. Beyond that, we'll switch to ESR 24, and so on.. | JBPiacentino: This means that Thunderbird and Thunderbird ESR will use Gecko 17, which will be updated for security and stability avery 6 weeks, for the whole 54 weeks ESR cycle duration. Beyond that, we'll switch to ESR 24, and so on.. | ||
Joachim Herb: I contributed to some (very) small patches for Thunderbird, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=519956 | |||
It took 6 month to get the patch into Thunderbird. This was already laborious. With the 6-week release cycle there was a chance to see your work included within a reasonable time. Now, if a new version of Thunderbird is only released once a year and a patch misses that opportunity, does it mean you have to wait for another year? This does not sound very motivating. | |||
R Kent: In the thread "Gecko versions for future Thunderbird releases" I discuss some of the possible organization of future releases. Using the terminology from that thread, according to my proposal you would land your patch on comm-central, which is synced to mozilla-central Gecko and would for sure land in the annual TB-next and TB-ESR (and would be available in EarlyBird on the aurora channel prior to that). If the patch does not cause interface changes, nor depend on the Gecko version, then it could be nominated for inclusion in the more frequent TB-Main (with releases perhaps quarterly). That is accomplished by pushing the patch to comm-beta. | |||
I think that is is a reasonable compromise that allows development to keep up with Gecko changes, while allowing more stability in TB-Main. | |||