Policies/Minor Point Release Policy: Difference between revisions

Revision as of 15:31, 27 February 2011

KDE provides minor point releases approximately every month after a major point release of the main modules.

As stable releases these are recommended to a wide user base who expect a high degree of stability. Changes should therefore be verifiable, reliable and regression free.

These releases must only contain:

Severe bugs: security vulnerabilities, severe regressions from previous releases, data loss bugs
Fixes to bugs which are easy to verify
Updated translations
Updated manuals

They must not contain:

API changes in public libraries
New strings

In case you need absolutely new API or new strings to fix a important bug, approval from the relevant teams is needed.

For API changes in public libraries you need the approval of kde-core-devel
For new strings you need the approval of kde-i18n-doc

Revision as of 11:50, 27 February 2011 view source Albert Astals Cid (talk \| contribs) KDEDevelopers, trusted 769 edits Created page with 'KDE Provides minor point releases approximately every month after a major point release. As stable releases these are recommended to a wide user base who expect a high degree of...'		Revision as of 15:31, 27 February 2011 view source Albert Astals Cid (talk \| contribs) KDEDevelopers, trusted 769 edits No edit summary Newer edit →
Line 1:		Line 1:
	KDE ~~Provides~~ minor point releases approximately every month after a major point release.		KDE provides minor point releases approximately every month after a major point release of the main modules.

	As stable releases these are recommended to a wide user base who expect a high degree of stability. Changes should therefore be verifiable, reliable and regression free.		As stable releases these are recommended to a wide user base who expect a high degree of stability. Changes should therefore be verifiable, reliable and regression free.