Change the release cycle to match actual situations (#16430)
* Change the release cycle to match actual situations * Update CONTRIBUTING.md Co-authored-by: zeripath <art27@cantab.net> Co-authored-by: Lauris BH <lauris@nix.lv>
This commit is contained in:
		
							parent
							
								
									e180456983
								
							
						
					
					
						commit
						efeb8e890b
					
				
					 1 changed files with 8 additions and 6 deletions
				
			
		|  | @ -3,12 +3,14 @@ | ||||||
| ## Table of Contents | ## Table of Contents | ||||||
| 
 | 
 | ||||||
| - [Contribution Guidelines](#contribution-guidelines) | - [Contribution Guidelines](#contribution-guidelines) | ||||||
|  |   - [Table of Contents](#table-of-contents) | ||||||
|   - [Introduction](#introduction) |   - [Introduction](#introduction) | ||||||
|   - [Bug reports](#bug-reports) |   - [Bug reports](#bug-reports) | ||||||
|   - [Discuss your design](#discuss-your-design) |   - [Discuss your design](#discuss-your-design) | ||||||
|   - [Testing redux](#testing-redux) |   - [Testing redux](#testing-redux) | ||||||
|   - [Vendoring](#vendoring) |   - [Vendoring](#vendoring) | ||||||
|   - [Translation](#translation) |   - [Translation](#translation) | ||||||
|  |   - [Building Gitea](#building-gitea) | ||||||
|   - [Code review](#code-review) |   - [Code review](#code-review) | ||||||
|   - [Styleguide](#styleguide) |   - [Styleguide](#styleguide) | ||||||
|   - [Design guideline](#design-guideline) |   - [Design guideline](#design-guideline) | ||||||
|  | @ -226,18 +228,18 @@ We assume in good faith that the information you provide is legally binding. | ||||||
| 
 | 
 | ||||||
| We adopted a release schedule to streamline the process of working | We adopted a release schedule to streamline the process of working | ||||||
| on, finishing, and issuing releases. The overall goal is to make a | on, finishing, and issuing releases. The overall goal is to make a | ||||||
| minor release every two months, which breaks down into one month of | minor release every three or four months, which breaks down into two or three months of | ||||||
| general development followed by one month of testing and polishing | general development followed by one month of testing and polishing | ||||||
| known as the release freeze. All the feature pull requests should be | known as the release freeze. All the feature pull requests should be | ||||||
| merged in the first month of one release period. And, during the frozen | merged before feature freeze. And, during the frozen period, a corresponding  | ||||||
| period, a corresponding release branch is open for fixes backported from | release branch is open for fixes backported from main branch. Release candidates  | ||||||
| master. Release candidates are made during this period for user testing to | are made during this period for user testing to | ||||||
| obtain a final version that is maintained in this branch. A release is | obtain a final version that is maintained in this branch. A release is | ||||||
| maintained by issuing patch releases to only correct critical problems | maintained by issuing patch releases to only correct critical problems | ||||||
| such as crashes or security issues. | such as crashes or security issues. | ||||||
| 
 | 
 | ||||||
| Major release cycles are bimonthly. They always begin on the 25th and end on | Major release cycles are seasonal. They always begin on the 25th and end on | ||||||
| the 24th (i.e., the 25th of December to February 24th). | the 24th (i.e., the 25th of December to March 24th). | ||||||
| 
 | 
 | ||||||
| During a development cycle, we may also publish any necessary minor releases | During a development cycle, we may also publish any necessary minor releases | ||||||
| for the previous version. For example, if the latest, published release is | for the previous version. For example, if the latest, published release is | ||||||
|  |  | ||||||
		Loading…
	
		Reference in a new issue