RFC: Release Management Going Forward

[Aaron J. Seigo]

On Friday, June 10, 2011 03:49:21 Harald Sitter wrote:
> 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 agree that this is the case on the desktop, but it would be rather useful 
for those working on non-desktop form factors. those of us working on tablets 
are already facing this issue.

it would also allow us to hit a greater number of distro's release cycles with 
new releases. right now we release twice per year, and there are more 
significant distro releases than that. which means some distros come out with 
something relatively old, and some with something newer. by shortening the 
cycle, a distro may ship something as close to their package freeze cycle as 
possible. to me, this is more palatable than trying to allign our releases to 
one specific downstream's release cycle.

it give us a smaller delta between each release, allowing us to do feature-
>stabilize cycles in smaller steps, which should hopefully mean better 
releases.

it can also relieve us of doing frequent bug fix releases as we do now: 
instead of a bug fix every month and a new feature release every 6, we could 
do an actual release every two. we would probably still do large promo 
treatments at time-based punctuations through the year and we may also elect 
to keep a "long term branch" that rolls over once a year where we backport 
critical fixes to (release could be left up to packagers?)

so while it won't have significant impact in terms of uptake on desktop 
focussed distros, i think there are significant advantages across the board 
for us.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110610/5322527d/attachment-0001.sig