Does this site look plain?

This site uses advanced css techniques

Steve Friedl's Evolution™ Tips

Evo Tip: Understanding Evolution Versioning

• Home
• Contact
• About
• TechTips
• Tools&Source
• Evo Payroll
• CmdLetters
• Research
• AT&T 3B2
• Advisories
• News/Pubs
• Literacy
• Calif.Voting
• Personal
• Tech Blog
• Evo Blog

Evolution™ is the payroll service-bureau system from iSystems, LLC, and though the vendor makes the usual kinds of feature and bugfix releases, the nature of the payroll business demands far more extensive updates.

Changes in tax rates for any of the thousands of jurisdiction in the United States (and creation of new ones), implementation of crazy employment rules, plus retroactive laws, all make keeping up with payroll a difficult business to be in.

The vendor releases these updates periodically, and we've observed some occasional confusion about which kinds are which. This Evo Tip means to clear that up.

Update Types

Each new version update published by iSystems on their SB support site has either one or two parts, each of which is a ZIP files to minimize download times.

Application version

This contains actual program code — .EXEs and .DLLs — and it updates the actual program code for Evolution. This is installed on the main RB machine, in the Versions\ subdirectory of the Evolution Management Console, and it's deployed to all the middle-tier machines in the Evolution system when activated in the EMC.

When an Evolution client logs in for the first time after an update, it automatically downloads these updated program codes to the local hard drive: this is what causes a longer than normal login time for Evo clients for the first connection after an update.

The application version number is shown in the Evo Local or Evo Remote title bar.

The filenames look like 9.0.31.1.zip.

SYSTEM database version

This is a Firebird backup for the SYSTEM.gdb database, and it represents tax rules and rates, reports, and many other employment-related constants. These are released much more often.

This is updated by stopping the package servers and performing a database restore of the SYSTEM.gbk file to the db server. Our clickrestore tool has been popular for this task.

These filenames look like 9-0-31-309_system.zip.

These two work hand in hand, and a general (but not universal) rule is that the Application and SYSTEM versions have to agree in the first three digits. Evolution always checks to make sure that the two parts are compatible with each other, and it reports a Database Mismatch error when the Evo client (Local or Remote) starts up. These mismatches should be resolved promptly.

Version update progression

To show the progression of versions, we'll follow two major Application version updates along with the associated SYSTEM databases:

When an Application update is released, it's always associated with a new SYSTEM database, and they must be installed together. Line #1 shows this pair of linked versions.

But subsequent (lines 2..7) releases publish just a SYSTEM database, and these go with the original 9.0.27.2 Application version on line 1.

But once the next Application version is released (line 8), then this forces another change in the series of SYSTEM databases.

We'll note that Evolution does not require sequential updates, so a service bureau that's on 9.0.26.x wishing to jump ahead may install Application 9.0.28.20 and (say) SYSTEM 9.0.28.302 directly, skipping the intermediate versions. All that matters is that the SYSTEM version match the Application version.

Most Evo administrators consider a SYSTEM database update to be safer than an Application+SYSTEM update, as the latter updates program code.

Because the SYSTEM database always implies a specific Application version number, most Evo admins refer to just the SYSTEM database version when referring to a version (i.e., "9.0.28.302" precisely nails down both the application and SYSTEM versions).

New-version announcements

iSystems send emails to the evolution-announce mailing list (which all Evolution administrators should be subscribed to) announcing new versions on the support site. These alerts include which items are to be updated as shown by these samples:

From: iSystems Support
Date: Tue, 20 May 2008 17:36:40 -0400
Subject: [Evolution-announce] The newest version of Killington is now available

Application:    9.0.28.20
System database:   9.0.28.296

The Killington Evolution installers can be found here: (link)

The Killington Evolution Help installers can be found here: (link)

Release Notes have been posted here: (link)

From: iSystems Support
Date: Mon, 23 Jun 2008 16:34:33 -0400
Subject: [Evolution-announce] The newest version of Killington is now available

System database:   9.0.28.306

The Killington Evolution installers can be found here: (link)

The Killington Evolution Help installers can be found here: (link)

Release Notes have been posted here: (link)

The absense of an Application version almost always means that it's a SYSTEM database update only, though this has not always been the case.

When to update?

We don't believe that every SB needs every version upon release, and that it's not wise to update automatically.

Instead, we recommend reviewing the Release Notes and Known Issues every time to see if the version being posted touches on issues important to your SB. Many are updates for narrow issues (say, a local tax for a small town in the midwest), and if none of issues matter, this may be a version to let pass you by for now.

The tax department is usually most well-equipped to identify issues that require attention, and of course iSystems Support will often close a ticket with the note that such-and-such a version fixed the issue.

Our general feeling is that SYSTEM DB updates can be made much more casually than Application updates, as the former has far less impact on the system as a whole. If there's a question about whether you need a new SYSTEM database, it's usually safe to just do it.

Application updates usually require a bit more caution, as they update program code on not only the Evolution middle tier (the Windows machines), but are downloaded to customers when they connect for the first time.

For Application updates (which of course also go with a SYSTEM update), we usually recommend holding off unless there something specific you need. At least one other SB undoubtedtly has to update immediately, and the evolution-tech and evolution-talk mailing lists usually shake out problems early.

We've observed that quarter-end usually involves updates that most SBs need right way.

But we'll note that no matter which kind of update is applied, they can always be rolled back.

Historical Versions

Evolution versions are named alphabetically for (mostly) towns in Vermont, and we've looked back on our records to find all these versions and their rough release dates. This information is presented more as trivia than as data necessary to run an Evolution system.

Note: from v19 through v22, Asure did not provide official names, so we've made up our own unofficial ones as noted.

See Also

• Evo Tip: Applying routine Evolution updates
• evo-sysver: Show current SYSTEM database version
• Clickrestore: One-click SYSTEM database updates

First published: 2008/06/26