]> source.dussan.org Git - gitea.git/commitdiff
Update CONTRIBUTING following #2329 discussion
authorAntoine GIRARD <sapk@users.noreply.github.com>
Fri, 25 Aug 2017 13:13:54 +0000 (15:13 +0200)
committerKim "BKC" Carlbäcker <kim.carlbacker@gmail.com>
Mon, 28 Aug 2017 17:08:24 +0000 (19:08 +0200)
Creation of release branch before end of release dev and releases candidates + follow semver semantic (minor, patch)

CONTRIBUTING.md

index 3ddabcbe30f611e57435c89d7a5f8e269ac8ec9f..7a6871680eccce31add0de37ceefa9a10cb361a9 100644 (file)
@@ -97,7 +97,7 @@ Please use your real name, we really dislike pseudonyms or anonymous contributio
 
 ## Release Cycle
 
-We adopted a release schedule to streamline the process of working on, finishing, and issuing releases. The overall goal is to make a major release every two months, which breaks down into one month of general development followed by one month of testing and polishing known as the release freeze. A release is maintained by issuing minor releases to only correct critical problems such as crashes or security issues. All the feature pull requests should be merged in the first month of one release period
+We adopted a release schedule to streamline the process of working on, finishing, and issuing releases. The overall goal is to make a minor release every two months, which breaks down into one month of general development followed by one month of testing and polishing 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 period a corresponding release branch is open for fix backported from master. Release candidate are made along this period for user testing to obtain a final version that is maintained in this branch. A release is maintained by issuing patch releases to only correct critical problems such as crashes or security issues
 
 The current release cycle is aligned to start on December 25 to February 24, next is February 25 to April 24, and etc. On this cycle, we also maybe publish the previous release minor version. For example, the current release version is v1.1, but we maybe also publish v1.0.2. When we publish v1.2, then we will stop publish v1.0.3.