Differences

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

--- versioning [2011/11/22 13:03] – [Version Compatibility] dyrcona
+++ versioning [2022/02/10 13:34] (current) – external edit 127.0.0.1
@@ Line 2: / Line 2: @@
-===== The Versioning Scheme (as of Evergreen 2.0.0) =====
+===== The Versioning Scheme (as of Evergreen 2.1.0) =====
 The Evergreen project uses a double-decimal format, such as "2.0.1", for both Evergreen and OpenSRF releases.
@@ Line 8: / Line 8: @@
 ==== Major, minor, and patch releases ====
-The first number (in our example, the number "2") is a "Major" version number.  This number is incremented when the release includes major updates and/or significant changes to infrastructure requirements. For example, Evergreen 2.0.0 increases the minimum required version of PostgreSQL from 8.1 to 8.4.
+The first number (in our example, the number "2") is a "Major" version number. This number is incremented when the release includes major feature updates.
-The second number (in our example, the number "0") is a "Minor" version number.  This number is incremented when the release includes minor feature updates with no significant changes to infrastructure requirements. For example, a new feature such as self-serve password resets required changes to the Evergreen Perl modules, catalogue HTML and JavaScript, new database tables, and configuration of action-trigger templates, but as it was possible to install on an existing system, only the minor version number needed to be incremented.
+The second number (in our example, the number "0") is a "Minor" version number.  This number is incremented when the release includes minor feature updates.
 The third number (in our example, the number "1") indicates the "Patch" number. This number is incremented for new releases that contain no new features: only bug fixes and updated translations are eligible for these releases.
-==== Alpha, beta, and release candidate 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.
+==== 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 (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.
-  * **beta**: features are complete, database schema is frozen for anything other than bug fixes, strings are frozen for translation
-  * **release candidate**: no show-stopper bugs; integration of new and updated translations; testing all functionality and upgrades from prior releases
-  * **Golden Master**: no show-stopper or critical bugs; release notes, installation and upgrade instructions are ready
+  * **alpha**: optional early release intended for testing, feedback, and documentation; may come at any point before beta
+  * **feature slush**: major planning for features is complete
+    * at this point, all significant features should either have been merged or at least have LP bugs and pullrequests
+    * 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 (strings frozen); testing all functionality and upgrades from prior releases
+  * **Golden Master**: no //critical// or //high// bugs; release notes, installation and upgrade instructions are ready
 ===== The Versioning Scheme (prior to Evergreen 2.0.0) =====
@@ Line 56: / Line 67: @@
 ===== Version Compatibility =====
-Different versions of Evergreen require different versions of OpenSRF.  TODO: fully populate this chart.  TODO: determine backwards compatibility, if any.
+Different versions of Evergreen require different versions of OpenSRF.
+^ Evergreen  ^  OpenSRF  ^  PostgresSQL ^ Dojo* ^  XULrunner  ^
+| 2.0 | 1.6 | 8.4 | 1.3.3  | 1.9.2 / 3.6 |
+| 2.1 | 2.0 | 9.0 / 9.1 | 1.3.3  | 1.9.2 / 3.6 |
+| 2.2 | 2.1 | 9.1 | 1.3.3  | 1.9.2 / 3.6 |
+| 2.3 | 2.1 | 9.1 | 1.3.3  | 3.6+ (14.0 recommended) |
+| master | master | 9.1 / 9.2 | 1.3.3  | 3.6+ (14.0 recommended) |
-^ Evergreen  ^  OpenSRF  ^  PostgresSQL ^ Dojo* ^  Ejabberd  ^ XUL  ^
-| 2.0 | 1.6 | 8.4 | 1.3.3 | ? | ? |
-| 2.1 | 2.0 | 9.0 / 9.1 | 1.3.3 | ? | ? |
-| master | 2.0 | 9.0 / 9.1 | ??? | ? | ? |
 * note: if you are installing from a tarball, the appropriate version of Dojo is included
 [[:start|Evergreen Dokuwiki Home]]