[Kde-accessibility] kdeaccessibility plan

[Gunnar Schmi Dt]

Hello,

> As it was said that releasing kdeaccessibility tarballs for KDE 3.1 and=
 3.0
> would be a good idea, and I think it is, I designed the following plan:
> 1) Impor the current stable versions of the applications, KMag, KMouseT=
ool,
> KMouth and KSpeech plug ins.
> 1.Bis) If someone is about to reach a stable point soon (KMouth may, fo=
r
> example), please, tell me, and we'll wait for that stable point if it's=
 not
> too far.

If there are no objections, I will publish KMouth version 1.0beta3 tomorr=
ow=20
and put the sources for that version into kdeaccessibility. That version =
will=20
not yet contain an updated documentation and no support for kttsd. I will=
=20
update the documentation and possibly add the kttsd-support once KMouth i=
s in=20
kdeaccessibility.

> 2) Make it work smothly with head, I can help with that.
> 3) Branch for 3.0 and 3.1 once it is stable enough.
> 4) Make sure 3.0 and 3.1 work in 3.0 and 3.1 (currently I can help with
> 3.1)
> 5) Release tarbals for 3.0 and 3.1.
> 6) Discontinue that releases unless for bugfixes.

Currently KMouth runs with KDE 3.0. I will branch once KMouth is in=20
kdeaccessibility and afterwards make shure that the 3.1 branch (if it is=20
neccessary, i.e., not just a copy of the 3.0 branch) and the head branch =
run=20
with the respective KDE versions.

> 7) Import the development/unstable versions of KMag, KMouseTool, KMouth=
 and
> KSpeech plug ins in kdeaccessibility head.
> 8) Go on developing them to reach another stable point in 3.2.

My plan is as follows:
1) Import the stable (or close-to-stable) versions of the applications in=
to=20
kdeaccessibility (e.g. until Fri, Jan, 17)
2) branch for 3.0, 3.1 and head and make sure that the branches run (e.g.=
=20
until Fri, Jan, 24)
3) do a i18n-string freeze on Fri, Jan, 24
3) produce a pre-release of kdeaccessibility without translations on that=
 week=20
end (until at latest Mon, Jan, 27)
4) produce a release candidate (with translations) three weeks later (tak=
e the=20
CVS version of Fri, Feb 14, publish the release candidate by at latest Mo=
n,=20
Feb, 17)
5) if all works fine, produce the final version of kdeaccessibility one w=
eek=20
later (take the CVS version of Fri, Feb 21, publish the release by at lat=
est=20
Mon, Feb, 24)
6) Discontinue that releases unless for bugfixes.
7) If tere are unstable versions of the applications outside kdeaccessibi=
lity=20
import them into kdeaccessibility.
8) Go on developing the head branch to reach another stable point in 3.2,=
=20
possibly with the freeze dates of the 3.2 release cycle.

These dates are ok for KMouth, they should also be ok for stable versions=
 of=20
the other applications. If they are too early for unstable versions to be=
come=20
stable, please reply, so that we can decide whether we want to wait for t=
hem.

Gunnar Schmi Dt