Introduction to VISTA Version Control: The Six Scales

The OSEHRA Forum project is ultimately about the VISTA software lifecycle, which in turn is about version control, which in turn is about complexity and change.
Medicine is extraordinarily complex and changes rapidly. Software like VISTA that fully supports medicine has to model it, which means it too must be extraordinarily complex and change rapidly. Accurately representing all this complexity and managing its change is partly an architectural problem (structuring the software to make such complexity comprehensible and manageable, a subject for another time) and partly a software-lifecycle problem, a version control problem (organizing the software updates to make such complex changes comprehensible and manageable).
We organize change into six scales.
1) VISTA dialects
2) codebases
3) applications
4) versions
5) patches
6) elements
I. VISTA dialects - such as VA VISTA or IHS RPMS - are reference versions of VISTA that are closely related but distinct enough that they must be managed separately. Every VISTA codebase in the VISTA world is derived from some VISTA dialect through a stream of software updates specific to that dialect. Knowing which VISTA dialect you are running is the foundational frame of reference for any VISTA adopter.
II. Codebases are snapshots of a clean, complete VISTA environment. People new to VISTA often imagine that focusing on codebases is the best way to manage VISTA, but future codebases are nearly useless to any VISTA adopter once they start using their codebase in production. To try to update their production codebase by replacing it with a new one would erase and/or corrupt all their production data (patient records, security, and so on). Codebases remain the sources and destinations for VISTA updates, but are rarely distributed or installed. Instead, we use the smaller scales for managing change.
III. Applications are strictly notional divisions of VISTA. That is, VISTA is not a system built by snapping together applications, and applications are not capable of being run by themselves. Each application is a suite of software elements that have in common that they (1) automate a common medical or support service, (2) are developed by the same development team, and (3) are typically organized and updated together. Applications are updated two ways:
IV. Versions are releases of the complete suite of software elements that make up an application. Every application is released as an initial version. Thereafter, the VISTA software lifecycle needs them to be updated every few years, so that (a) changes in medicine, technology, or other VISTA applications can be reflected properly in the application; (b) the count of patches and more importantly the increasingly complex dependencies among interrelated patches can be reset to a clean slate (see below); and (c) the application architecture can be combed through in detail to clean up any growing architectural distortions caused by patches' incremental updates and sometimes hurried development. Due to changes in VA policy during the mid-1990s, most applications have had this scale of change frozen, which is causing growing problems in VISTA's architecture and functionality.
V. Patches are small(ish), incremental upgrades to a version of an application. Each patch collects together the software elements affected by some bug fix(es) or enhancement(s), so they will be installed together as a transaction. Since VISTA exploits the Von Neumann effect (discussed elsewhere) derived from crossing the traditional boundaries between programs and data, patches often involve updates to the parts of the database that hold code or code fragments. In turn, this sometimes requires writing conversions or running other kinds of system transformations as part of the patch. Generally speaking, when an application version has received fifty to a hundred patches, it's time to release a new version of the application to reduce the complexity of patch management. Phases One and Two of the OSEHRA Forum project are mostly focused on this scale of change.
VI. Software elements - such as routines, options, or remote procedures - are rarely updated individually, almost always instead as part of a quantum update in patch form. As a result, VISTA's traditional version-control support focusaed on patches and versions and gave inadequate support for tracking changes to individual software elements over time. Traditional version-control systems, by contrast, focus on codebases and individual software elements, which makes them useful for VISTA in supplementing its version-tracking toolkit but not useful for its change-management, since VISTA must instead be managed at the version and patch scales. Extending VISTA with traditional version-control tools does offer a lot of value though in helping to make changes to individual software elements and differences between codebases easier to see and understand.

The Patch Module and KIDS - the main applications affected by this project - have traditionally focused on scales 4 and 5. This project aims to improve their support for all six scales.
On today's OSEHRA Forum open-source project-group meeting, our Scrum Master Christopher Edwards will - I hope - extend Sprint Six another week, since we're all still working on our tasks from last week. OSEHRA Forum meetings are open to the entire VISTA community, so drop by and say hi:
When: Monday, 29 September 2014, 1:00 p.m. Eastern time
Dial-in: 1-650-479-3207
Access code: 669 171 453