Some Ideas & Current Issues Eric Bickle 20.Aug.03 02:51 PM Lotus Notes General All ReleasesAll Platforms
The problem is not knowing which fixes were fixed where. A good example is the "Server Availability Index" that was flaged as marked fixed in the 6.0.1 CF3 but not 6.0.2 CF2 or 6.0.3.
The easiest fix is to make the "Release" field in your fix list database multi-value. If, for example, you fixed the Server Availability bug in 6.0.1 CF3, 6.0.2 CF2, and 6.0.3, you would select all three. And if you decided to create a 6.0.0 CF1 later, after you "fixed" that bug in the new CF for 6.0.0, you would just add it to the list of releases.
The main problem is people not knowing which fixes have been done where. This is compounded by the fact that the CF packs (seemingly) come out on different dates, what happens if you ship a CF for 6.0.2 and the next day find a servere fix for 6.0.1, then ship it a few days later. The users won't know which systems have actually been secured.
All of these fixes are creating a severe incremental upgrade nightmare as well. Have you ever tried upgrading a Domino 6.0.1 CF1 server to Domino 6.0.2? Get you're QA department to try it! If a 6.0.1 user upgrades to 6.0.1 CF3, then how are they supposed to upgrade to 6.0.2 or 6.0.3 if the 6.0.2 incremental installer doesn't support 6.0.1 CF3? Do they format their server and start from scratch?
While I understand the reasoning behind the critical fixes (administrators not wanting to go to new revisions), it doesn't work in real life. It creates hellish nightmares for things like the incremental updates. The new versions are patches as well and also include fixes, just not critical fixes. If an administrator doesn't trust upgrading to a new version number because of QA issues (needs additional testing, etc), then why do you expect critical fixes to be any different? I believe that there have been crashes and other severe issues with critical fixes in the past - why would administrators trust them any more in that case?
If I had my choice, I would drop the multiple critical fix branches and just have two code branches. One for the "latest" release (6.0.3) and one for the current releases critical fixes (6.0.2 CF2). That way you don't run into the "which bug has been fixed where" questions, and you don't have the incremental upgrade nightmares that thousands of Lotus administrators are currently having. Failing that, I would at the very least change the fix list database so that the "release" field is multivalue.