As a growing community, to be efficient, we must have a common understanding of Where to Commit, but we must also get a common understanding of When to commit.
This page will attempt to describe a consensus on when to commit so we can all converge and be ready to release according to the Lifecycle.
This part needs to be much precise
when | what |
1 month before | technical release (feature-freeze) where all translations (with automatic syntax checking) and promotional material can be prepared. |
2 months before | All minor new features should be in trunk so they can be tested in time for the release. |
3 months before | All major new features should be in trunk so they can be tested in time for the release. |
The big underlying questions:
The closer we are to the release, the more risk free your contributions should be
In case of doubt, coordinate with release coordinator. These are questions that come to mind:
These should be done fairly early in a cycle. So we have several months to iron-out all the issues. A backward-compatibility layer should be provided. Ex.: Permission cleanup, new modules system, etc. It's a good idea to start these in an Experimental branch.
How will upgrades be handled?
These can arrive quite late. If they are not ready for prime-time, just tag as experimental.
http://live.gnome.org/ReleasePlanning/Freezes