Minor Point Release Policy
mpyne at kde.org
Sat Dec 12 00:56:49 CET 2009
On Friday 11 December 2009 14:58:11 Lubos Lunak wrote:
> On Friday 11 of December 2009, Jonathan Riddell wrote:
> > Over at Kubuntu we're trying to concince our technical board that its
> > ok to put KDE minor point releases in updates. However it seems
> > there's no formal rules for what is or isn't acceptable in minor point
> > releases. I think it would be a good thing to have some since it
> > gives guidance on what should or shouldn't be put into release
> > branches after release. So I wrote some down quickly. Does this make
> > sense to adopt for KDE? Additions welcome.
> * Fixes to bugs which are easy to verify and have a report in bugs.kde.org
> So if I notice a problem, I have to first report it?
I'm almost willing to go this route just because it will artificially inflate
my bug-closing numbers. :P
> They must not contain
> * API changes
> * New strings
This will basically be "me too" but there have been string changes in minor
releases when the string was flat-out wrong before. This is coordinated with
the translations teams but not impossible (and nor should it be).
I think I've even personally fixed a kdelibs bug that required an API
addition. I'm not sure I'd agree with tilting the "stability" slider all the
way up and forbid these types of fixes for slipstreaming KDE releases to
However I like to offer solutions where possible. So, assuming KDE switches to
git it should be easy to have separate branches for branch releases and
"really stable" releases, e.g.
| | | | /-----/
where * indicates "stable" bugfixes that would be applied to both -branch and
-stable, and & indicates bugfixes which might cause regressions that packagers
try to avoid and would therefore be applied only to branch.
KDE SC would be released from -branch and packagers could adopt -stable
BUT, this would be that much more work for us, for (what seems to me at least)
an uncertain gain. So even though I've thrown out the idea I don't really like
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20091211/05d716c7/attachment.sig
More information about the release-team