[Zope-dev] Trying to summarize the requirements for the package version story

[Lennart Regebro]

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?