Open Source Integrated Library System
About Us FAQs Documentation Blog Chat Mailing Lists Evergreen Blogs Download
 

User Comments

Versioning

The Versioning Scheme

The Evergreen project follows a version numbering scheme similar to that used for the Linux kernel. This scheme uses a double-decimal format, such as “3.2.74”.

The first number (in our example, the number “3”) is a “Major” version number. This number will be incremented upon the release of an “extreme” update (such as a totally rewritten user interface).

The second number (in our example, the number “2”) is a “Minor” version number. If this number is odd (IE: 1,3,5,etc.), it indicates that the version is not yet classified as stable (IE: Alpha, Beta, Release Candidate). Likewise, even numbers (2,4,6,etc.) indicate that the version is considered final and stable (although, as with any software, bugs probably still exist to be discovered). Increments in this number usually indicate some minor updates, such as a slightly changed user interface or included features that were previously modules.

The third number (in our example, the number “74) indicates the “Build” number. This number is usually incremented when very minor changes are implemented in the release. Examples usually include bug fixes, typos, and the like.

Version Suffixes

You will occasionally see a version with an extra field. Examples might be “1.1.95-RC1”, “2.4.161-SMP”, “4.2.33-Foobar-14”. Some common suffixes include:

  • RC1: Standing for “Release Candidate number 1”, this indicates the version is nearly final (post beta). Minor bugfixes may be committed, but eventually it is expected to make this stable (IE: an even minor number).
  • SMP: This case indicates an added feature or patch. SMP often means “Symmetric MultiProcessing”, meaning it is made to utilize multiple-processor systems.
  • Foobar-14: This type of example indicates who the builder is, and what their build number is. With Open-Source Software, you will often find some who will make their own changes or distribute their own sources or binaries. In the example “4.2.33-Foobar-14”, 4.2.33 indicates the “official” version number, Foobar indicates the user/company/etc., and 14 indicates their build number. An example might be “1.2.95-Debian-2”, meaning that it is the second build of Debian's release, and based on the 1.2.95 version of the “official”.

Samples of the Versioning Scheme in use

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: Build 12 of a development version

2.2.95: The 95th build of the 2nd minor release of the 2nd major release.

Checking the installed version of Evergreen

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

Version Compatibility

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

Evergreen OpenSRF PostgresSQL Dojo*
1.2 0.9 8.1 / 8.2 n/a?
1.4 1.0 8.1 / 8.2 1.3.2
1.6 1.2 8.2 / 8.3 1.3.2 / 1.3.3
2.0 1.6 8.4 1.3.3
trunk 1.6 8.4 ???

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

Evergreen Dokuwiki Home

 
versioning.txt · Last modified: 2010/08/23 09:53 by dbs
 
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Debian Driven by DokuWiki