RFC: Release Management Going Forward

[Sebastian Kügler]

Hey Tom, :)

On Thursday, June 09, 2011 22:21:01 Tom Albers wrote:
> I think we have to respond to the current problems with the beta 1 release.
> The adaption among distro's wasn't what we are used to due to our unclear
> message about if this layout is going to be final.

Yeah, I think we've created quite a mess, and we need to make our releases 
"backwards compatible" for our downstreams, those that consume it. 

> 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 :)

> The big problem here is that the release-team has no resources to generate
> these monolithic tarballs. If we were to decide this, we need help from the
> buildsystem to adapt our scripts to generate them. The question to the
> buildsystem guys is, if anyone wants to stand up and help with this.

I'm all for it. And I volunteer Alex! ;-)

Let me dump my brain and add how I see release management going forward from 
here:

= 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?)

= 5.x =
* KDE SC releases ship "latest stable" of everything
* Apps require KDE Frameworks version >= 5.x
* Independent version numbering of apps
* Plasma Desktop, Netbook, Active as separate apps
* Apps can do intermittent releases, or skip cycles
* KDE Frameworks 5.x
** Mostly source compatible to 4.x
** Strong backwards compatibility commitment, automatic tests if possible
** split out tarballs for KDE Qt Addons and Solutions (see discussion on kde- 
   core-devel)
** monolithic tarballs for easier packaging
** "high level git integration tool(s)" to make the lives of those who build 
   from source easier

= Notes =
* precise layout for split frameworks to be decided on k-c-d
* first frameworks release aimed at "as soon as possible after Qt 5.0"
* everything else up to k-c-d
* code is released from master branches, which should always be stable (see 
  git workflow thread on k-c-d)
* target groups for frameworks are specifically: distros, app developers, 3rd 
  party developers
* more frequent releases?

The above provides a rough plan that is in line with the results from the 
Platform11 sprint in Randa. I've deliberately spared many details, to give us 
back some high-level overview.

discuss =)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9