Branching Out

Following on from the previous entry regarding hotfix packages and the branches, here is a fictitious product life cycle:

    hotfix_branches

At time T1 the product is released (RTM).

After RTM there is a GDR hotfix package “a” released – this package will contain both GDR and LDR versions of the updated binary.

Later, LDR hotfix package “b” is released – there is no update for the GDR branch, so installation of this package will move the binary to the LDR branch – this version contains the code changes from “a” and “b”.

A second GDR hotfix package “c” arrives after this, so contains updates for both branches again:
- if no updates have been installed for this binary, the GDR version is applied
- if only update “a” has been installed, the GDR version is applied
- if update “b” has been installed, the LDR version is applied

The GDR version of update “c” contains the changes in updates “a” and “c” only, whereas the LDR version also contains the changes in update “b” – this is to avoid regression if update “b” was applied to address a non-security issue.

 

At time T2 the first Service Pack arrives (SP1).

On installing SP1, the binary is moved back to the GDR branch and will contain all the changes in updates “a”, “b” and “c”.

Following SP1, an LDR update “d” is released – this package contains only an LDR branch update, but contains versions for RTM and SP1.

Later, GDR package “e” is released – this package will be the biggest so far as it contains 4 flavours:
- RTMGDR (for systems before SP1 where no updates are applied, or only “a” and/or “c”)
- RTMLDR (for systems before SP1 where update “b” or “d” have been applied)
- SP1GDR (for systems with SP1 which have not had “d” applied)
- SP1LDR (for systems with SP1 which have “d” applied)

 

At time T3 the second Service Pack arrives (SP2).

On installing SP2, the binary is moved back to the GDR branch and will contain all the changes in updates “a” thru “e”.

As with hotfix package “d” previously, updates “f” and “g” are LDR hotfixes that contain updates for the LDR branch only, but for SP1 (n-1)and SP2 (n), and update “h” is a GDR update package similar to “e”.

This is why you see the minimum Service Pack level for hotfixes – there is no update produced for the RTM branch (change control would become a nightmare, testing would take far too long, and the package size would become ridiculous in size).

 

At time T4 the product enters extended support – there will be no further Service Packs and there is no support for SP1.

GDR package “i” is created at some point after T4 – it will contain GDR & LDR versions of the update but only for the SP2 branch.

This is effectively where Windows 2000 is today – only security updates are produced for it, and anything before SP4 is unsupported.

 

The thing to bear in mind here is that Service Packs contain all updates leading up to the binary entering lockdown – so you are not just getting the changes from security updates, you get all the changes made (including internal changes that may not result in a KB article at all).

 

Regarding support lifecycles, assuming the “n and n-1” support principle:
T1-T2 : Support for RTM only (no other branch exists)
T2-T3 : Support for RTM and SP1
T3-T4 : Support for SP1 and SP2
T4 onwards : Support for SP2 only, extended support up to End-Of-Life (EOL)