RFC: Release Management Going Forward

[Alexander Neundorf]

On Friday 10 June 2011, Sebastian Kügler wrote:
> 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! ;-)

Yes, sure, but I'm away from this noon until Sunday evening.
Is this needed already now for 4.7 ?

I was hoping to have some more weeks to give it more testing and finish it.
("it" being the "Superbuild" CMakeLists.txt, which provide builds in old-style 
KDE modules or in the future maybe even an all-in-one build using CMakes 
ExternalProject feature).
In git there is a repository superbuild now, but it's not yet done.

What still needs to be done:
- add special handling DESTDIR
- add handling for tags
- maybe some work on the implementation of ExternalProject in cmake

For which modules is this right now ?
kdesupport, kdegraphics, more ?

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

"There is no 5" ;-)

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


Alex