RFC: Release Management Going Forward

[Harald Sitter]

On Friday 10 June 2011 03:31:20 Sebastian Kügler wrote:
> > I suggest that we also add monolithic tarballs, starting from beta 2.
> > This way we have split and combined tarballs. And I suggest that we
> > continue to do this for the whole 4.7 cycle. And we need to discuss
> > this again for 4.8.
> 
> Yep, the layout of the tarballs should be the same as for the 4.6.0 release.
> On top of that, I suggest not changing the layout for 4.8. See below :)

I think what hurts most on a packaging level is the uncertainty whether the 
layout is going to change again (now or later).

So, I'd agree with not changing the (split) layout at all anymore and in 
addition provide monolithic tars.

> = KDE SC 4.x =
> * monolithic tarballs, layout like 4.6.0 release
> * no disruption in packages
> * git migration should not have effect on released tarball layout to keep
>   packagers' lives easy
> * optional split tarballs (split/ subdirectory?)

What should be worked out is whether the layout of apps/components that are 
already split is going to stay the way they are split now, or whether that 
might change completely for 5.x (thus discouraging packager adoption at this 
time unless they see value in having intermediate changes). 

> = 5.x =
> = Notes =
> * target groups for frameworks are specifically: distros, app developers,
> 3rd party developers
> * more frequent releases?

More frequent releases does not translate to more frequent adoption though, so 
I doubt it would have much affect for distros and 3rd party developers (I 
really do not think latter will build frameworks from source if their 
distribution already provides everything ready to go).
Just something to keep in mind. If a distro is releasing once a year, the 
better part of the target audience will still get new (QA'd/integrated) 
versions only once a year.

-- 
Harald