[Kst] trunk is feature frozen

[George Staikos]

On Thursday 24 November 2005 14:20, Andrew Walker wrote:
> Wouldn't it be simpler for you to create a branch for 1.2.0 and then
> have everyone else simply carry on in trunk. Any critical changes
> in the trunk could then be merged into the 1.2.0 branch.

   This will undoubtedly slow down 1.2.0 release.  Experience in KDE tells us 
this, and I think that all the feedback I received also supports this.  Here 
are the reasons:

1) Developers focus on new stuff and don't fix the broken things.
2) Fixes in trunk don't make it into the branch.
3) Fixes in the branch don't make it into trunk.
4) Too much effort is spent on merging patches in general, especially if #2 
and #3 aren't a problem.
5) Not enough people working on and using the code we're about to release.
6) We will get no translations for 1.2.0. (Translation team only works in 
trunk.)

   On the other hand, features are well defined and typically straightforward 
to merge after 1.2.0.

   The important thing right now is getting a stable Kst and getting 1.2.0 
out.  Once this is done, other than some updating work, the core of Kst is 
pretty much stable architecturally and we can move ahead with new features.  
Hopefully Kst will stay more stable in trunk than it got this summer.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/