I'm trying to get my head around the package versioning requirements. It seems to me that we have the following requirements: 1. We need to be able to in a buildout say "I want to use Zope version 3.4, thanks", and the buildout should then download the latest versions of the relevant Zope packages that make up Zope 3.4. 1a. If bugfixes are released bin/buildout will install and upgrade the bugfixes. 1b. If a version of zope.something is released that is NOT compatible with 3.4, but compatible with 3.5, that version will NOT be downloaded. 2. We need to be able to in a buildout say "I want to use Zope version 3.4.5, thanks", and the buildout should then download that the set of eggs that is Version 3.4.5. 2a. If bugfixes are released for Zope 3.4 these will NOT be downloaded. (2b. Although if there is a way to make security fixes to be automatically downloaded, that would be neat) 3. We need to be able to in a buildout say "I want to use Grok 1.2" and Grok 1.2 will automatically depend on a specific version of Zope, say 3.4.5. I.e., we want to be able to "extend" Known Good Sets. 4. We want to in the buildout be able to specifically override a version of a package, I say that we want to use zope.whatever 3.5.6, although it is not an "approved part" of the Zope version we have specified. 5. We want an egg that the buildout depends on to be able to override the version of a package. I.e, if the buildout installs. zc.coolpackage, and that requires zope.something 1.3.2, although the Zope 3.4 KGS specifies 1.2.3, 1.2.3 should be used. 1 can not be solved by having version information in the packages, because I think the list of versions, AKA the "Known Good Set" is going to have to be updated more or less manually with releases, right? Because you can't just take the last version of everything, because sooner or later somebody releases somthing that breaks it. And updating the list would require you to re-release a package, which is bad. 2a can be solved by version information in packages, 2b can not. 3 needs an extension mechanism. 4 and 5 are version conflict resolution problems, which already exists, right?