forked from Shiloh/githaven
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
@ -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 New Issue
Block a user