[Zope3-dev] Re: Zope 3 releases?

[Tres Seaver]

-----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 <jim at zope.com> 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          tseaver at palladion.com
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-----