-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote: > Roger Ineichen wrote: >> Hi Tres >> >>> Whoever released those two eggs (the '.dev-r#####' ones) need >>> to release "real" updated packages, and then grok 0.11.1 >>> should be released using them. >>> >>> DEATH TO FAUX PACKAGES! >> As far as I understand, this does not happen if you >> depend on a KGS, right? >> >> Does the grok release not use the KGS from Stephan? >> > > Not yet. We intend to look at that list at some point. Of course the KGS > probably doesn't contain recent enough packages to support the REST > changes.
If the REST stuff depended on unreleased versions of upstream packages, then it should not have been merged until those packages were released in an acceptable (non-snapshot) form. > The other problem with KGS is that I absolutely want to fix lists of > packages into Grok itself and never rely on any system that can cause > the list of packages that could be updated. KGS will get bugfix > releases. These will inevitably break something on occassion. I have no > idea what will happen once 3.5 packages will start to appear, either. 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. - 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. 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. 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 iD8DBQFHNS+v+gerLs4ltQ4RAl/rAJ9lDeB9nOXGab+/uAithNjeMeREkwCgguHF 5qA0vftURPPCW7SR2yZVTmk= =NBMc -----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 )
