Qt-contributors-summit-2014-Long term releases: Difference between revisions
		
		
		
		
		
		Jump to navigation
		Jump to search
		
				
		
		
	
AutoSpider (talk | contribs)  (Decode HTML entity names)  | 
				m (Categorize)  | 
				||
| Line 1: | Line 1: | ||
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}  | {{Cleanup | reason=Auto-imported from ExpressionEngine.}}  | ||
[[Category:QtCS2014]]  | |||
=Long-term releases=  | =Long-term releases=  | ||
Latest revision as of 17:35, 6 January 2017
| This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.  | 
Long-term releases
- We’ve managed to make 6-month releases
- No change in schedule time: we want to continue doing 6-months
 - Modulo adjustments so we don’t release too close to vacation periods
 
 - Release process is improving
- Ability to do package creation much more quickly
 - Unification of packages with enterprise/commercial will also reduce workload
 
 - How long should long-term releases be?
- More than every 2 releases
 - Probably every 18-24 months (3 or 4 releases)
 
 - First LTS release should be either 5.3 or 5.4
- Digia wants to do a business check first and will let us know
 - 5.3 is a good candidate because we focused on stability
 
 - Doing LTS buys us a few benefits:
- We can deprecate platforms and compilers after the LTS release
 - Targets to be dropped as soon as feasible:
- Windows XP
 - OS X 10.6
 - MSVC 2008
 - GCC < 4.6
 
 
 - Procedure:
- Bugs to be fixed should be security bugs, P0, P1
- P2 can be fixed, exceptionally, if no workaround is possible
 
 - Fix is applied to the LTS branch and then merged to the next releases
 - Releases should be based on amount of changes made, like what we’re doing for 4.8
 
 - Bugs to be fixed should be security bugs, P0, P1