Differences

This shows you the differences between two versions of the page.

--- versioning [2013/01/07 08:55] – [The Versioning Scheme (as of Evergreen 2.0.0)] dyrcona
+++ versioning [2017/11/06 22:16] – [Major/Minor release process (Non-patch releases)] dbw2
@@ Line 15: / Line 15: @@
-==== Alpha, beta, and release candidate releases ====
+==== Major/Minor release process (Non-patch releases) ====
-During the process of finalizing a new major or minor release, the release manager will normally create a series of alpha, beta, and release candidate releases for the purposes of testing, providing feature previews, and supporting documentation and translation efforts. The progression from //alpha// through //release candidate// represents the development team's increasing confidence in the stability and production-readiness of the code, until the //Golden Master// (final release) is published.
+During the process of finalizing a new major or minor release, the release manager will normally create a series of alpha (optional), beta, and release candidate releases for the purposes of testing, providing feature previews, and supporting documentation and translation efforts. The progression from //alpha// through //release candidate// represents the development team's increasing confidence in the stability and production-readiness of the code, until the //Golden Master// (final release) is published.
 The first alpha release for a given major or minor increment will be labelled //alpha1//, the second alpha release will be labelled //alpha2//, etc. Once the progression from alpha to beta has been made, no further alpha releases will be published.
-  * **alpha**: features are mostly complete, release is intended for testing, feedback, and documentation
+In addition to actual releases, there are other common deadlines involved in each release process, so we define those here as well.
-  * **pre-beta**: a brief period (generally a few days) between alpha and beta intended primarily for developer verification of feature merges
-    * the pre-beta period begins with a hard cutoff for merging in feature branches
+  * **alpha**: optional early release intended for testing, feedback, and documentation; may come at any point before beta
-    * a release is prepared, but no external announcement is made, and no download link is published
+  * **feature slush**: major planning for features is complete
-    * developers have two days to check for obvious problems caused by incorrect or missing commits; problems are corrected as needed
+    * at this point, all significant features should either have been merged or at least have LP bugs and pullrequests
-  * **beta**: features are complete, database schema is frozen for anything other than bug fixes, strings are frozen for translation
+    * generally scheduled two to three weeks before beta
+  * **feature freeze** and **string slush**: features complete
+    * no feature branches should be merged beyond this date
+    * templates updated for translators; string changes should be avoided
+    * generally one week or less before the beta release
+  * **beta**: first "complete" release
+    * all further commits should be for bug fixes, translations, or release/build process improvements
+    * database schema is frozen for anything other than bug fixes
   * **release candidate**: no //critical// bugs; integration of new and updated translations; testing all functionality and upgrades from prior releases
   * **Golden Master**: no //critical// or //high// bugs; release notes, installation and upgrade instructions are ready