mirror/forgejo
1
0
Fork 0
mirror of https://codeberg.org/forgejo/forgejo.git synced 2024-12-01 05:36:19 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 9

Change the release cycle to match actual situations (#16430)

Browse source 
* 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:
Lunny Xiao 2021-07-15 02:03:00 +08:00 committed by GitHub
parent e180456983
commit efeb8e890b
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
CONTRIBUTING.md
View file

@ -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