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 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.

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 (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.

In addition to actual releases, there are other common deadlines involved in each release process, so we define those here as well.

• 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

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.

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

Evergreen Dokuwiki Home