Minor Point Release Policy

[Michael Pyne]

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 
downstream packagers.

------

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.

\
 +-[4.4-branch]--*--*--*--&--&--*
 |               |  |  |  /-----/
 \-[4.4-stable]--*--*--*--*

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 
bugfixes.

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 
it.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20091211/05d716c7/attachment.sig