VERSION MANAGEMENT is the process of keeping track of different versions of software components or configuration items, and the systems in which these components are used. It also involves ensuring that changes made by different developers to these versions do not interfere with each other. RECALL the three terms from the planning topic: VERSION an instance differing in some way from others VARIANT functionally identical, non-functionally distinct RELEASE a version distributed to customers KEY CAPABILITIES of a version management system: VERSION AND RELEASE IDENTIFICATION managed versions are assigned identifiers when submitted to the system STORAGE MANAGEMENT rather than keeping a complete copy of every version, the system stores DELTAS — the differences — which historically was essential and is still how most systems work internally CHANGE HISTORY RECORDING all changes made to all components are recorded and can be viewed INDEPENDENT DEVELOPMENT different versions may be developed in parallel, and the system tracks which components are in which version PROJECT SUPPORT the system can support the development of several projects sharing components DELTA STORAGE, quantified — why it matters: Suppose a 400 KB source file edited 500 times, each edit changing about 2 KB. FULL COPIES: 500 × 400 KB = 200,000 KB ≈ 195 MB DELTAS: 400 KB + 499 × 2 KB = 1,398 KB ≈ 1.4 MB → a 143× reduction FORWARD DELTAS store the original plus changes to reach each later version; BACKWARD DELTAS store the LATEST version complete plus changes to reconstruct older ones — which is better, because the most recent version is the one most often retrieved and needs no reconstruction. CODELINES AND BASELINES — the two dimensions: a CODELINE is a sequence of versions of source code, with later versions derived from earlier ones. Codelines normally apply to ONE COMPONENT. a BASELINE is a definition of a specific system, specifying the component versions included plus a specification of the libraries used, external dependencies, configuration files and so on. Baselines cut ACROSS components. A baseline is therefore a horizontal slice across many vertical codelines, and it is what you need to rebuild a system rather than a file. BRANCHING AND MERGING: BRANCHING creating a new codeline from a version in an existing codeline, developed independently MERGING creating a new version by merging separate versions from different codelines Merges may be AUTOMATIC where changes do not overlap, and require manual resolution where they do.

A SYSTEM RELEASE is a version of a system distributed to customers. It is NOT simply the executable code: WHAT A RELEASE CONSISTS OF (Sommerville): · configuration files defining how the release is configured for a particular installation · data files needed for system operation · an INSTALLATION PROGRAM used to help install the system on target hardware · electronic and paper DOCUMENTATION describing the system · PACKAGING and associated publicity designed for that release RELEASE MANAGEMENT IS COMPLICATED BY THE FACT THAT CUSTOMERS MAY NOT WANT TO INSTALL A NEW RELEASE. This is the central practical difficulty, and it has consequences: · some customers may be happy with the current system and consider an upgrade to be an unnecessary cost and risk · a new release may provide new features they do not need · they may have to pay for training or new hardware · CONSEQUENTLY YOU MAY HAVE TO SUPPORT SEVERAL RELEASES SIMULTANEOUSLY, which multiplies maintenance cost · you cannot assume that customers have installed all previous releases, so a new release may have to work as an upgrade from ANY earlier release — which is a combinatorial testing problem FACTORS INFLUENCING RELEASE PLANNING — when to release: TECHNICAL QUALITY OF THE SYSTEM if serious faults are reported which affect many users, it may be necessary to issue a fault-repair release; minor faults may be repaired by patches PLATFORM CHANGES a new version of the operating system may force a release LAWS AND REGULATIONS legislative changes may require modification, with a legally mandated date COMPETITION a new competitor release may force a response MARKETING REQUIREMENTS the marketing department may have committed to a date CUSTOMER CHANGE PROPOSALS accumulated requests may justify a release RELEASE CREATION — the process of creating the collection of files and documentation that comprise a system release. The activities: · the executable code and all associated data files must be identified · configuration descriptions may have to be written for different hardware and operating systems · update instructions may have to be written for customers who configured the system themselves · scripts must be written for the installation program · electronic and paper documentation must be prepared · all this must be packaged for distribution RELEASE DOCUMENTATION — what must be recorded, because it is what makes a release reproducible and supportable: · all the release components must be recorded, with the versions of source code used to create the executables · copies of all source code, executables, configuration files and data files must be KEPT AND ARCHIVED. You should be able to recreate any released system after the development system has moved on. · the versions of the operating system, libraries, compilers and other tools used should be recorded — since these may be required to build exactly the same system at some later date

HOW MANY RELEASES TO SUPPORT — the cost calculation nobody does until it hurts. Suppose a release requires, per year: security patch backporting 12 person-days answering support questions 8 person-days testing each patch on that version 10 person-days ───────────────────────────────────────────────── 30 person-days per supported release per year supporting 2 releases = 60 person-days/year supporting 4 releases = 120 person-days/year supporting 7 releases = 210 person-days/year ≈ 10 person- months, or roughly one full-time engineer doing nothing but keeping old versions alive AND IT IS WORSE THAN LINEAR, because a security fix must be adapted to each older codebase, and the oldest ones have diverged most. THIS IS WHY VENDORS PUBLISH SUPPORT WINDOWS — "we support the current release and the previous one" is not meanness, it is the only way the arithmetic works. UPGRADE-PATH TESTING, the combinatorial problem: if customers may upgrade from any earlier release to the newest, then with n prior releases there are n upgrade paths to test. With 7 supported releases that is 7 paths, each needing its own data migration test. Vendors reduce this by requiring STEPPED UPGRADES — "upgrade to 3.x before upgrading to 4.x" — which turns n paths into a chain of 1-step paths at the cost of customer inconvenience. RELEASE STRATEGIES — the modern spectrum: BIG-BANG RELEASE Ship to everyone at once. Simple, and the failure mode is that a defect reaches 100% of users before anyone notices. STAGED / PHASED ROLLOUT Release to 1% of users, then 5%, 25%, 100%, watching error rates and key metrics at each stage with predefined HALT CRITERIA. WORKED — the arithmetic of why this works: 100,000 users, a defect affecting 3% of sessions big-bang: 3,000 users hit it before you react staged at 1% first: 1,000 users in the cohort, 30 hit it → detected at 30 affected users instead of 3,000, a 100× reduction in blast radius The saving is exactly the inverse of the first cohort's share, which is why the first stage should be small. CANARY RELEASE Route a small fraction of live traffic to the new version while the old version continues serving the rest, comparing the two directly. Distinguishes "the new version is broken" from "something else changed today", which a staged rollout alone cannot. BLUE-GREEN DEPLOYMENT Two identical production environments. Deploy to the idle one (green), verify it, then switch traffic. ROLLBACK IS A TRAFFIC SWITCH, which is seconds rather than a redeploy — and that speed is the entire point, because a rollback you can perform in seconds is a rollback you will actually perform. FEATURE FLAGS / TOGGLES Deploy the code with the new behaviour disabled, then enable it for cohorts independently of deployment. SEPARATES DEPLOYMENT FROM RELEASE — the code ships without the feature being live, so a problem is disabled rather than rolled back. The cost is flag debt: every flag is a branch in the code and a doubling of the state to test, so flags must be removed once a feature is fully enabled. ROLLING RELEASE / CONTINUOUS DELIVERY No large releases at all; every accepted change is releasable and shipped continuously. This eliminates the "supporting seven releases" problem entirely by having only one — but it requires customers who accept continuous change, which is true of hosted services and false of installed software. THE PATTERN ACROSS ALL OF THEM: every one of these strategies is a way of REDUCING THE COST OF BEING WRONG, either by limiting who is exposed (staged, canary), by making reversal cheap (blue-green, flags), or by making each change small enough that the risk is low (continuous delivery). None of them claims to prevent defects — they assume defects will ship and reduce what happens next. ROLLBACK AND THE ONE-WAY DOOR: a rollback is easy for code and hard for DATA. If release 4.0 migrated the database, rolling back to 3.9 means the schema no longer matches the code. The standard discipline is BACKWARDS-COMPATIBLE MIGRATIONS — deploy the schema change first in a form the OLD code still works with, then deploy the new code, then remove the old columns in a later release. Three deployments instead of one, and every step is individually reversible.