From Fedora Project Wiki
| Line 2: | Line 2: | ||
We are asking for exception to ship 1 4.x update in Fn release. | We are asking for exception to ship 1 4.x update in Fn release. | ||
== Reasons == | == Reasons == | ||
* upstream release schedule - it's somewhere in the middle of Fedora release timeframe | |||
* 4.x.y is the only stable and supported version by upstream | |||
** it's not easy to backport bug fixes in a such complex codebase | |||
* users visible changes are slowing down quickly with higher 4.x releases | |||
== Our update process == | == Our update process == | ||
Revision as of 16:03, 7 September 2010
Fedora KDE Plasma Desktop update policy
We are asking for exception to ship 1 4.x update in Fn release.
Reasons
- upstream release schedule - it's somewhere in the middle of Fedora release timeframe
- 4.x.y is the only stable and supported version by upstream
- it's not easy to backport bug fixes in a such complex codebase
- users visible changes are slowing down quickly with higher 4.x releases
Our update process
Our update process is quite complex to assure quality of final -> stable push.
- the new 4.x packages are built for Rawhide
- packages are pushed to kde-unstable repository
- input is requested from the first testers
- bug tracker is created to collect 4.x bugs and known regressions
- once most of bugs are fixed -> go/no-go meeting (kde sig meeting)
- update is pushed to updates-testing repository (usually for a few weeks)
- we closely tracking bugs and regressions - we have lot of testers
- once most of bugs/criticals are fixed -> stable go/no-go meeting
- final updates push