Unfortunately for the aspiration of technological unitarianism, an inevitable and usually undesired consequence of software development is the fact that it is rarely finished, on-going development projects produce multiple releases of the core product, albeit releases of different versions. Variations in software versions may be minor or significant, sometimes so significant that different versions no longer work with each other or with their different data/objects. Conventional management and engineering thought considers version management to be a compliance issue. Switching version is relegated to the status of a 'data migration' problem but we all know this is not the whole story; objects may need to be regenerated, operation with existing systems may need to be guaranteed, users and customers may need to adapt, even transform, their work activities.
In the past clever object versioning schemes have allowed some systems to be patched incrementally ad-infinitum: IBM is particularly notable with its system of patching by applying PTFs (Program Temporary Fix) on mainframe, Microsoft with its service packs, Apple and its Updates. New releases of the main product would include changes commensurate with patches within their architecture, while existing systems could evolve continuously, sometimes without needing to be re-initialised or restarted.
In terms of the management of source code and the underlying software architecture we see in recent years the increasing use of the term "technical debt", indicating that a product has been patched and extended incrementally for so long that it needs wholesale "refactoring" to make its source code manageable or comprehendible again.
The practical reality of developing and keeping multiple versions in synch is usually considered to be a problem of "porting". Porting is the recompilation and rewriting of a single product for multiple platforms. Platform could be construed as computer (architecture) plus operating system combinations, competing software platforms (e.g. browsers), devices (mobiles), or running/execution environments (shells, IDEs) and other software environments (e.g. word processors, databases, social media, etc.).
Whether as software source code or objects the most recent build, the most recent release is usually considered to be a unified version, the most current and best available. Consequently customer-Product migration from one product version to another is generally treated as a technical and compliance issue. A matter of keeping up with the latest version.
However, on the matter of unitarianism and the holy grail of a single source code and object, the latest and greatest available to all at all times, no old versions - the 'technology' is a bit of a red herring. Why not have two or more products on two or more platforms? Yes you want them to be as similar as possible and perhaps ultimately allow for a grand unification/simplification. Compile, build, package and source code unification at some point in the future may well benefit your firm by making maintenance and new development more efficient. But it comes at a price, the cost is complexity, indirection, and further convoluted inter-dependencies on yet more versions of "other" software (usually sourced from 3rd parties). Unitarianism is a holy grail, and probably unachievable.
Ask yourself, what is the value of a single build, a single platform, a single architecture? Changes and differences are after all inevitable if you release for other platforms. Embrace the change, embrace the difference, allow for multiple versions, just be sure you know what they are and why you have them.
Notes for further reading
- Software maintenance and evolution: a roadmap. Bennett & Rajlich, 2000.
- Software Maintenance Maturity Model (SMmm): the software maintenance process model. April et al., 2005
- A Framework for Software Product Line Practice SEI. Currently V5 (is there irony in the idea of versioning product versioning policy?) (also see slides at www.cs.helsinki.fi)
- Experiences with Software Product Family Evolution. Riva & Del Rosso, 2005
- A Cost Model for Software Product Line. Böckle et al. 2004
- Open source software maintenance process framework. Koponen & Hotti, 2005
- Issues in Software Maintenance. Lientz, 1983
- A field study of the software design process for large systems. Curtis et al. 1988
- Salion, Inc.: A Software Product Line Case Study. Clements & Northrop, 2002
- Software factories: assembling applications with patterns, models, frameworks and tools. Greenfield & Short, 2003
- Software Product Lines, and software platforms - Yaser Ghanam at InfoQ on Mar 07, 2011