Minor Point Release Policy

[Lubos Lunak]

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.
>
> http://techbase.kde.org/Policies/Minor_Point_Release_Policy/Draft

* Severe bugs: security vulnerabilities, severe regressions from previous
   releases, data loss bugs 

 Every bug is severe to somebody. If you draw the line too far, it means that 
every single stable release will be full of non-major bugs, because that 
simply happens with x.y.0 and people won't be allowed to fix them.

* 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?

* Updated translations

They must not contain 
* API changes 

 I expect you mean "no new API", since everything else is ruled out already. 
And fixes occassionally do require new API. It is not recommended to have 
older kdelibs than anything else from KDE SC anyway.

* New strings 

 Similar to above. Unlike with API I don't know for sure if this happens, but 
I'd be surprised if not when needed.


 Frankly, I'd prefer if we rather wrote down the existing guidelines, 
with 'use common sense' as first, and named them as such (=guidelines), 
rather than having a policy and pointless discussions about details that do 
not matter.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz