RFC: Release Management Going Forward
sitter at kde.org
Fri Jun 10 03:49:21 CEST 2011
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.
More information about the release-team