RFC: Release Management Going Forward
Sebastian Kügler
sebas at kde.org
Fri Jun 10 03:31:20 CEST 2011
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
More information about the Kde-buildsystem
mailing list