Another release engineering principle: never let a binary distribution out the door without including an automated deinstall/upgrade. Otherwise your first release may be your last. This has sort of happened to me with the KB, I wrote it in a rush and didn't pay attention to installation and deinstallation. As a result, subsequent releases had no idea where to find the original one, and upgrading was a manual process that inevitably got messed up, which became the source of complaints and problems.
That's why I've been so obsessed with figuring out how to deinstall the KB's required perl modules. I consider a good, clean deinstall a prerequisite to any further work on the KB project. It means extra work and delays before that first release, but it's well worth it in the long run.
Never let an unidentified distribution get out the door. By out the door I mean beyond the confines of your development team, and that includes managers, 3rd party users of your code, testers, etc. Tag your entire module in CVS in preparation for a distribution. Then do a CVS export by that tag. If you're building binaries, build in a clean environment. With a binary distribution, make sure the tag gets embedded into the final executable, and is made accessible to users via an About dialog, a --version argument, or something similar.
If you don't do these things you will quickly find yourself in a world of hurt, as end users come to you with problems in strange, unidentifiable executables. Their problems will not be traceable back to a particular set of source files, and you may never be able to reproduce the build that they have, much less reproduce the problems they're reporting.
Everything needs to be traceable back to its source. Once you've gone back to the source, builds need to be reproducible, which is yet another argument for completely automating the build process to eliminate the possibility of human error.
Every good geek is sitting at home reading the win2k sources right now.
Been trying to figure out a way to programmatically deinstall a pocket pc app from the desktop side, without any luck. CEAppManager doesn't seem to support a /remove flag; MS docs suggest that it is manual, shrouding the fact in language like "the user calls the Application Manager from the desktop computer." The user "calls?"
Of course if we're on the pda side already it's easy, so I'm wondering if writing a Setup.dll which deinstalls old versions before installing the new one will work. Doubt it though--probably CEAppManager will complain before ever invoking the dll pda side.
Yay: Embedded Visual Basic 3.0 has a /make option that should allow one to compile projects from the command line. Instead it segfaults. Am downloading the 2002 edition to see if anything changed.
70.8 Megabyte turds. That is what I am currently downloading from MS in order to patch SQL Server 2k so that, hopefully, I can replicate a database across two servers without it crapping out. Three such turds. Guys, if you just released the source & 10k source patches every once in a while, wouldn't this be a lot easier?