[k3b] What happens after 2.0

[Sebastian Trueg]

On 03/18/2010 02:16 AM, Markus wrote:
> If no, here's my proposal:
> - Create a branch (eg /branches/extragear/multimedia/k3b/2.0) that'll receive 
> bugfixes only and keep the string freeze and open trunk for feature 
> development and string changes (I already have a list of English typos I 
> encountered while translating K3b).

This is what has been done always with all major K3b releases.

> - Backport crucial bugfixes to the branch for two or so months (depending how 
> much work that is).
> 
> - Tell distributors that they can safely use that branch to generate update 
> packages (seems like they currently hesitate to put new 2.0 betas in their 
> regular update repos and rather ship the alpha that was current when the last 
> "release season" was in fall).
> I'd volunteer to bug the openSUSE maintainers about it.

I am against allowing to build packages from svn. Frequent bugfix
releases are the better choice. And those will be more frequent since
nothing will be as much work as the port from kde3 to kde4.

> - Encourage distributors to submit bugfixes and that they can of course update 
> that branch for their entire 18-24 months support cycle just like they do for 
> KDE SC releases.
> 
> - To minimize the amount of bug reports for "old" K3b versions, I suggest that 
> new releases are made late winter and/or late summer to be picked up by 
> Fedora, Kubuntu, and Mandriva in their spring and fall releases.
> This is not a suggestion for a 6 months release cycle, btw. Releases can 
> happen more or less frequently, but missing those mainstream distos' version 
> freeze by a few weeks can't in our interest. ;-)

That sounds like a good idea. I was never able to keep any release dates
back in the day. But Michal seems to be more efficient that way. :)

Cheers,
Sebastian