We should distinguish between authoring the Windows build-the-installer code, and running that code. "Making a Zope 2 Windows release" consists of _running_ the build-the-installer code, and is easy. It's actually easier than building a Zope 3 Windows release: once the Python tarball, Zope 2 tarball, and pywin32 installer are downloaded, building a Zope 2 release consists of typing one command in a Cygwin shell: WinBuilders/buildout zope That's it. _Authoring_ the Zope 2 build-the-installer code has been a royal PITA, but work is needed there only when packaging gimmicks change. Like moving to zpkgtools, or moving away from them again, or moving to a different packaging system for one of the components (like Python moving from a Wise installer to an MSI installer for 2.4, or pywin32 earlier moving from a Wise installer to a distutils installer). Across the long life of Zope 2.7, those things changed very little, and as a result very little needed to change in the build-the-installer code across 2.7's life. 2.7 Windows releases remained easy to build across that time (granting that Mark Hammond did the work to adjust to pywin32's packaging changes). 2.8 Windows releases were/are similarly easy to build. A lot of new work was needed for 2.9, due to Python and zpkgtools changes. I also took the opportunity to "upgrade" from InnoSetup 4 to version 5, which introduced a much easier scheme for managing the custom dialog screens in the Zope installer. All of that ended up making the build-the-installer code substantially simpler, to the point where it now seems kinda goofy to use makefiles at all in the process. Makefile mazes are inscrutable, and are particularly ill-suited to the true nature of this task: "unpack various tarballs, and rearrange them like so". Finishing a Windows release of Zope 2 or Zope 3 takes much longer than just minutes, unless you skip testing. If you do skip testing, then it's minutes for both. Testing Zope as a Windows service is harder for Zope 3, because the Zope 3 installer doesn't (but the Zope 2 installer does) install or start the service, or auto-stop and remove the service when Zope is uninstalled. BTW, Zope3 _could_ do that too with a suitable post-install/pre-uninstall script, which is something InnoSetup automates for Zope2. It can take a Windows expert some days to author Zope2 build-the-installer changes when packaging fashions change (whether Zope's or the repackaged components'). InnoSetup is the least of the problems there, and while MSI is the coming fashion, slinging MSI code appears to require much more knowledge than slinging InnoSetup declarations. The idea that it takes "Windows expertise" to write an InnoSetup declaration is wrong: such lines merely say "take the files you find _here_ now, and put them _there_ when the installer runs". For example, this is the entire Inno code needed to install Zope 2's lib/ directory: Source:"lib\*.*"; DestDir: "{app}\lib"; Flags: ignoreversion recursesubdirs That kind of stuff is truly trivial. It does take Inno expertise to create and manage the installer's dialog screens ("manage" == e.g., if the user chooses not to have the installer create an instance home, then the dialog asking for the instance home's directory shouldn't be shown), but those typically don't change across releases.