-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote: > On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote: > >> On 10/6/07, Jim Fulton <[EMAIL PROTECTED]> wrote: >>> - We need to decide what a Zope 3 release is (or maybe multiple >>> flavors). I favor copying the linux experiences, but have an open >>> mind. >> I'm not sure what you mean with that, > > I mean we need to decide what a release is.
Presuming agreement on the "known good set" (KGS) term, I would think that we have two candidates for what makes up "platform releases" Frozen Releases - ---------------- A frozen release would consist of: - A single, "frozen" KGS (index pages cannot change after release). - Scripts / tools which target that KGS, and create from it a standalone environment whcih includes the selected diestributiongs for each project in the KGS. E.g.: o An easy_install'able meta-egg with pinned versions, referencing the KGS index as 'index_url'. The egg would also include scripts and other entry points used to configure the platform environment (e.g., install zope.conf and site.zcml from skeletons, etc.) o A bootstrappable zc.buildout with "pinned" versions for all packages, or which relies on the frozen meta-egg for pinning. o A 'virtualenv' derivative, again probably leveraging the "frozen" egg. It would probably be fairly straightforward to generate the "meta" egg given the manifest. In fact, the "meta" egg should probably load the pinned versions from a config file which was also used to generate the frozen index page. These releases would be useful for: - Testing third-party packages which extend the platform. - Reproducing bugs reported against the platform - Giving to newbies as a "safe" starting point. The public versions of them would probably *not* be good for use in production deployments, because they cannot be updated with bugfixes. Some users might maintain their own versioned frozen releases for such uses, and handle updates by re-installing and migrating their data). Such a release would be analogous to a bootable ISO for a Linux distribution: if you run from the CD, you *know* what software is present, without any question. I would note that the script I posted a week or so ago for building package index pages from a directory full of source distributions would be a perfectly adequate tool for constructing such a KGS: simple copy or link all the "frozen" distributions into a directory and run the script. Once you've verified that the installation regime works from the generated files, you *never touch them again*. Updatable Platform Releases - --------------------------- An updatable platform release would consist of: - A KGS whose index pages were manually updated from time to time with carefully-selected new distributions of existing packges. - An installation regime, as above, which uses the KGS as its 'index_url', but *pins no packages* (whether in the "meta" egg, buildout.cfg, or whatever). o This regime should also contain / bootstrap scripts which couls be used to do automated updates from the KGS, like 'yum update' / 'apt-get upgrade'. In this case, generating the "meta egg" (or equivalent) should be unneeded: that egg could just be managed within the KGS itself. In a typical environment, the meta egg would likely never be updated all all (because it contains no software beyond the parts used to generate the environment). Such a relase would be analogous to an installed Linux distribution, with update repositories pre-configured. Maintaining the KGS in this case is harder, and could probably use a little more tooling. Once we have the tools, then tweaking them to allow generating a "frozen" release will be simple. In that mode, the two flavors of release here could be thought of as like "tags" and "branches" in the CVS sense (not SVN, which doesn't really have tags). 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 iD8DBQFHCoBx+gerLs4ltQ4RAnz3AJ0fBLZfO/oSbBr37L1LGp/bpAAtZQCgs0gg zShIqAl+sFbdCRKMHOhAH4A= =vl1V -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com