Minor Point Release Policy
l.lunak at suse.cz
Fri Dec 11 20:58:11 CET 2009
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.
* 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
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
More information about the release-team