release schedule proposal

[Boudewijn Rempt]

On Wednesday 02 February 2011, Inge Wallin wrote:

> I may have misunderstood, but if I understood correctly I'm very sorry to have 
> to say that I hate this. The reason is that it is a developer-centric way to 
> work rather than a user-centric.
> 
> I'm sure it will be very ego-boosting for us developers to get new versions 
> with new fancy features out there as soon as possible.
> 
> But as a user, I expect to be able to update to either a new version with new 
> features and possibly also new bugs *or* a more stable release with no new 
> features but also definitely less bugs.
> 
> If this is the way that we will do things, then the user will live in a state 
> of perpetually changing set of bugs and more or less well-working new 
> features.
> 
> For a short time, until we reach something like a big enough feature set that 
> a real organization can use it, then perhaps this could be a way forward.  But 
> I know that admins at larger installations prefer stability much before new 
> features.  And stability is what will suffer with this scheme.

But we don't have that sort of users at all -- there are no admins with big installations of koffice or calligra. We don't have the kind of users who value stability over experimentation, since there hasn't been an end-user release of KOffice since 2007. The only app with something approaching a userbase is Krita, and there the users are all for having the possibilities they ask for in their hands as soon as possible.

What we do have is an opportunity to show that there is progress because we are in a situation where master is no longer unstable like trunk used to be, but can be kept quite stable, while still receiving new features on a regular basis.

And in the end, having frequent snapshot releases _is_ a stopgap until we reach the release scheme Cyrille proposed: four releases a year, of which one gets bug fixes for a longer period.

-- 
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org