Difference between revisions of "FeatureFreezing"

From Inkscape Wiki
Jump to navigation Jump to search
m (Spelling fix.)
 
(Deleteme)
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
=== Feature Freeze Mode ===
In the release protocol [[CreatingDists]], it is intended that at there is around one week's feature freeze ahead of the 'Hard Freeze'.


In the run-up to CreatingDists, for a short time preceding the tagging of the release it's a good idea to
(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.
hold off on adding new features or doing other major changes like architectural changes to the code
that 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,
Whilst I am probably happier than most in using 'process' to ensure software quality, we ought not to go too far down that route!
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!