|(2 intermediate revisions by one other user not shown)|
|−|=== Feature Freeze Mode === |+|
| || |
|−|In the run-up to CreatingDists, for a short time preceding the tagging of the release it's a good idea to |+|
the , to or the that the .
|−|hold off on adding new features or doing other major changes like architectural changes to the code | |
might decrease its stability. Whether a change is minor enough to be "ok" is left to the developer's | |
|−|judgement, and they're trusted to be conservative and careful. | |
| || |
|−|The most useful activity to do during a feature freeze is to locate and/or fix bugs that produce crashes, |+|
most to , to go that
|−|and to do so with the smallest amount of change to the codebase possible. If a "proper" fix requires | |
|−|architectural changes or redesign of the code, consider writing that up as a post-release task. | |
|−|----- | |
|−|It might be useful to branch off a release branch a week before making the release. Hopefully most people using CVS would switch to this branch at this time. Then only bug fixes can go into that branch. --[[Ted]] | |
Latest revision as of 08:50, 15 February 2006
In the release protocol CreatingDists, it is intended that at there is around one week's feature freeze ahead of the 'Hard Freeze'.
(Ben) Note that though virtually every HOWTO on open source software describes these stages in the release process, Inkscape seems to be uniquely punctilious (or shares with the Debian that honour) in observing (or at least documenting the observance) of them.
Whilst I am probably happier than most in using 'process' to ensure software quality, we ought not to go too far down that route!