The Evergreen project uses a double-decimal format, such as "2.0.1", for both Evergreen and OpenSRF 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 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 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.

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.

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
• 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
  • a release is prepared, but no external announcement is made, and no download link is published
  • developers have two days to check for obvious problems caused by incorrect or missing commits; problems are corrected as needed
• 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

Prior to the Evergreen 2.0.0 release, we used a triple-decimal format for Evergreen releases and a double-decimal format for OpenSRF releases.

0.90.1: The very very first usable version. "Quick and dirty". Basically, a "proof of concept".

1.0.0: The very first version considered "final" and ready for deployment

1.1.12: The 12th patch release of the 1st minor revision of the 1st major version.

2.2.95: The 95th patch release for the 2nd minor revision of the 2nd major version.

You can issue an OpenSRF call against any Perl service to retrieve the installed version of Evergreen. For example, issue the following command in srfsh:

srfsh# request open-ils.cat opensrf.open-ils.system.ils_version

Received Data: "1-2-2-1"

------------------------------------
Request Completed Successfully
Request Time in seconds: 0.012489
------------------------------------

Different versions of Evergreen require different versions of OpenSRF. TODO: fully populate this chart. TODO: determine backwards compatibility, if any.

* note: if you are installing from a tarball, the appropriate version of Dojo is included

Evergreen Dokuwiki Home