GNOME 2.9.x is an unstable development series intended for testing and hacking purposes. Like the Linux kernel, GNOME uses odd minor version numbers to indicate development status, so this unstable 2.9.x series will eventually become the official 2.10 stable release. There are many ways you can get involved.
Suites & Module ListsFor more information about each suite of software in this release, including a list of proposed and final modules, see: |
Release TeamSee the Release Planning page for more information about the GNOME Release Team and process. If you need help, email the Release Team (release-team at gnome.org). Subscribe to devel-announce-list for release-team and other developer-related announcements. |
Testing and BugsSet up a safe testing platform following Andrew Sobala's Testing Guide, and join the GNOME Bugsquad's weekly Bug Days. Check the 2.9 Bugs Report for things to fix! :-) |
If you use evolution and evolution-webcal, you can subscribe to the totally elite webcal schedule! Do it! DO IT NOW! (Also available via http).
| Week | Date | Task | Big Picture |
|---|---|---|---|
| September 2004 | |||
| 1 | September 20th | ||
| 2 | September 27th | ||
| October 2004 | |||
| 3 | October 4th | ||
| 4 | October 11th | 2.8.1 tarballs due | First 2.8.x maintenance release - translations, plus bug and performance fixes. |
| October 13th | 2.8.1 release | ||
| 5 | October 18th | ||
| 6 | October 25th | ||
| November 2004 | |||
| 7 | November 1st | 2.9.1 tarballs due | First 2.9.x release! Go wild. Maintainers who wish to propose their modules for inclusion should speak up now. :-) |
| November 3rd | 2.9.1 release | ||
| 8 | November 8th | ||
| 9 | November 15th | ||
| 10 | November 22nd | ||
| 11 | November 29th | 2.9.2 tarballs due | |
| December 2004 | |||
| December 1st | 2.9.2 release | ||
| 12 | December 6th | 2.8.2 tarballs due | Second 2.8.x maintenance release - translations, plus bug and performance fixes. |
| December 8th | 2.8.2 release | ||
| 13 | December 13th | ||
| 14 | December 20th | 2.9.3 tarballs due | |
| December 22nd | 2.9.3 release | Slushy API/ABI Freeze: developer APIs should be almost frozen at this point. | |
| 15 | December 27th | ||
| January 2005 | |||
| 16 | January 3rd | ||
| 17 | January 10th | 2.9.4 tarballs due |
API/ABI Freeze: developer APIs should be frozen at this point. Feature and Module Freeze: new modules and functionality are chosen now. String Change Announcement Period: All string changes must be announced to both gnome-i18n@ and gnome-doc-list@. UI Change Announcement Period: All user interface changes must be announced to gnome-doc-list@. |
| January 12th | 2.9.4 release | ||
| 18 | January 17th | ||
| 19 | January 24th | 2.10.0 Beta 1 (2.9.90) tarballs due | UI Freeze: No UI changes may be made without approval from the release-team and notification to the GDP. |
| January 26th | 2.10.0 Beta 1 (2.9.90) release | ||
| 20 | Jaunary 31st | ||
| February 2005 | |||
| 21 | February 7th | 2.10.0 Beta 2 (2.9.91) tarballs due | String Freeze: no string changes may be made without confirmation from the l10n team (gnome-i18n@) and notification to both the release team and the GDP (gnome-doc-list@). |
| February 9th | 2.10.0 Beta 2 (2.9.91) release | ||
| 22 | February 14th | 2.8.3 tarballs due | Third and final 2.8.x maintenance release - translations, plus bug and performance fixes. |
| February 16th | 2.8.3 release | ||
| 23 | February 21st | ||
| 24 | February 28th | 2.10.0 Release Candidate 1 (2.9.92) tarballs due | Hard Code Freeze: no source code changes can be made without approval from the release-team. Translation and documentation can continue. |
| March 2005 | |||
| March 2nd | 2.10.0 Release Candidate 1 (2.9.92) release | ||
| 25 | March 7th | 2.10.0 tarballs due | |
| March 9th | March 9th: 2.10.0 release! | Hard Code Freeze ends, but other freezes remain in effect for the stable branch. | |
Reminder: When you create a stable branch, be sure to remember to let release-team, desktop-devel-list, gnome-doc-list, and gnome-i18n know. This is especially important if you branch before the stable release. An email also needs to be sent if you decide to use an older stable branch for this release as well.