D means it’s a build with debugging enabled, e.g. through the compiler flag -D or Constant DEBUG; in the code. This is good for development and testing, especially combined with the extended set of metaverbs, but for release you do not want to see a D at the end of the version number.
S means it’s compiled to have strict error-checking at runtime, which is on by default. This is good for development and testing, but not recommended for a release because it makes the game bigger and slower. To turn it off, pass the compiler flag -~S, either on the command line or as a compiler directive with !% in the source file. (Thanks Fredrik!)
R means the RUNTIME_ERRORS constant is set greater than 0. This is also good for development and testing. The author’s guide suggests setting it to 0 for a release build to avoid bugging the player about non-critical errors.
Thus, development and testing builds are likely to have the letters “SDR”, but release builds are probably going to not have any letters at all at the end.
(Yes, I figured it out on my own but there was no clear web search hit for this so I thought I might make one.)
If you start building a game using the code skeleton minimal.inf, you get a good start, including a few lines at the top to set compiler options to make the game smaller and faster. This includes -~S, to turn off strict error-checking, as strict error-checking has a severe impact on both file size and speed. At least for a release build, meant to be playable on 8-bit machines, strict error checking should always be disabled.
Additionally, it’s generally advicable to set RUNTIME_ERRORS to 0 when making a proper release. This means the library will keep quiet about problems it spots which don’t make the game crash. This makes the game file smaller and stops the library from breaking player immersion with complaints about programming errors.
And now that I read it more closely again, I realise it also says about strict checking that
it makes Inform code both bigger and slower, we usually recommend game authors to disable it, and this is done on the first line of the game template minimal.inf (“!% -~S”)
although this wasn’t in the “Before release” section so I missed it at first. This confirms what Fredrik said in this thread.
The documentation for PunyInform really is very good. Rare these days.
The first form of IFID is the correct form for both Inform 6 and 7.
The second form is a fallback that is used for games where the author hasnt put an IFID in them, possibly because they came out before the IFID standard emerged.
Yeah, the drawback of the old-style (automatically assigned) IFIDs is that they change with every new build. New-style (randomly generated) IFIDs are consistent across builds, which is better for identifying particular works of IF.