-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Tres Seaver wrote: >> A KGS needs to have the following properties: >> >> - The "generation zero" of any KGS is an empty set of revisions. >> >> - By default, any revision N of a KGS starts out as a "draft" version >> which is an empty layer over version N-1. Changes to the draft >> then shadow any versions in the prior revision. >> >> - Once "finalized" / "published", a given revision of a KGS can >> *never* be changed. > > I sympathize with this thinking, but as far as I understood Jim and > Stephan last night, there seems to be the goal to make a KGS for a whole > stable release branch, e.g. "Zope3.4", and keep on adding bugfix > releases. So there doesn't seem to be a consensus yet on how we should > manage KGSs.
Doing only that would be like having a release branch but no tags, i.e., unacceptable. Creating "frozen snapshots" (like CVS/SVN) tags after adding and testing new versions shouldn't be any harder than making a tag is today. >> - Any KGS can be derived from the published version of another KGS, >> with additions of new distributions / versions and updates of >> versions for underlying distributions. >> >> - In conjunction with a "find-links" site which promises never to >> remove any distribution which has been included in a published >> revision of a KGS, the current 'version.cfg' (and workalike) >> files are sufficient to establish a KGS. Without that promise, >> however, those files can't be considered as defining a KGS. > > That makes more sense to me than the locked down index. > >> Therefore, >> >> - Given that all distribution versions mentioned in a KGS are >> stored at a trusted / reliable URL, any immutable KGS revision >> can be trivially transformed into a PyPI package index: each >> distribution will have exactly one allowed version, which will >> point to a single URL on a reliable server. > > Right, I suppose that can be arranged on top of the version.cfg thing. I > find the locked down index approach attractive because it works with > pure setuptools, and it largely takes the responsibility out of Joe > Middleclass Developer's hands. That is also its greatest weaknesses > because doing anything that's not in the KGS requires some situps, for > instance managing a find-links location with the extra packages you want > to install. The locked down index is also exclusive, two orthogonal KGSs > are best merged using the version.cfg approach, it seems. If we have software which can generate the pacakge index at a URL for a KGS, then it could certainly generate a 'version.cfg' as well, to support buildout. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNazm+gerLs4ltQ4RAswyAKDaSgJSIw32gckbd9ctLUX+tgt6GQCbB9ON pYBf589Zdj/0aSihzXfzMvY= =RlBH -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
