versioning
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| versioning [2012/04/12 11:54] – [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 " | The Evergreen project uses a double-decimal format, such as " | ||
| Line 8: | Line 8: | ||
| ==== Major, minor, and patch releases ==== | ==== Major, minor, and patch releases ==== | ||
| - | The first number (in our example, the number " | + | The first number (in our example, the number " |
| - | The second number (in our example, the number " | + | The second number (in our example, the number " |
| The third number (in our example, the number " | The third number (in our example, the number " | ||
| - | ==== 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. | 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. | ||
| - | | + | 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 | + | |
| - | * the pre-beta period begins with a hard cutoff for merging in feature | + | |
| - | * a release is prepared, but no external announcement is made, and no download link is published | + | * **feature slush**: major planning |
| - | * 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**: | + | * generally scheduled two to three weeks before |
| - | * **release candidate**: | + | * **feature |
| - | * **Golden Master**: no show-stopper or critical bugs; release notes, installation and upgrade instructions are ready | + | * no feature branches should be merged beyond this date |
| + | * templates updated | ||
| + | * generally one week or less before the beta release | ||
| + | * **beta**: | ||
| + | * all further commits should be for bug fixes, translations, | ||
| + | * database schema is frozen for anything other than bug fixes | ||
| + | * **release candidate**: | ||
| + | * **Golden Master**: no //critical// or // | ||
| ===== The Versioning Scheme (prior to Evergreen 2.0.0) ===== | ===== The Versioning Scheme (prior to Evergreen 2.0.0) ===== | ||
| Line 59: | Line 67: | ||
| ===== Version Compatibility ===== | ===== Version Compatibility ===== | ||
| - | Different versions of Evergreen require different versions of OpenSRF. TODO: fully populate this chart. | + | Different versions of Evergreen require different versions of OpenSRF. |
| ^ Evergreen | ^ Evergreen | ||
| Line 65: | Line 73: | ||
| | 2.1 | 2.0 | 9.0 / 9.1 | 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.2 | 2.1 | 9.1 | 1.3.3 | 1.9.2 / 3.6 | | ||
| - | | master | + | | 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) | ||
| * note: if you are installing from a tarball, the appropriate version of Dojo is included | * note: if you are installing from a tarball, the appropriate version of Dojo is included | ||
| [[: | [[: | ||
versioning.1334246042.txt.gz · Last modified: 2022/02/10 13:33 (external edit)