Re: Re: Zope 3 releases?

Stephan Richter <[email protected]> Mon, 8 Oct 2007 18:49:02 -0400
Newsgroups gmane.comp.web.zope.zope3
Message-ID <[email protected]>
On Monday 08 October 2007 15:09, Tres Seaver wrote:
> 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
> ----------------

I started commenting this section until I saw the one below. I personally d=
o=20
not see much benefit from the frozen release. That said, it would be trivia=
l=20
to create one from the updateable version below. I have already scripts for=
=20
this, which are checked in as part of Jim's PyPI mirror tool.

> Updatable Platform Releases
> ---------------------------
>
> An updatable platform release would consist of:
>
> =A0- A KGS whose index pages were manually updated from time to time with
> =A0 =A0carefully-selected new distributions of existing packges.
>
> =A0- An installation regime, as above, which uses the KGS as its
> =A0 =A0'index_url', but *pins no packages* (whether in the "meta" egg,
> =A0 =A0buildout.cfg, or whatever).
>
> =A0 =A0o This regime should also contain / bootstrap scripts which couls
> =A0 =A0 =A0be used to do automated updates from the KGS, like 'yum update'
> =A0 =A0 =A0/ 'apt-get upgrade'.

This is pretty much done. See http://download.zope.org/zope3.4. I have chec=
ked=20
in the tools in zc.mirrorcheeseshopslashsimple. Buildout itself serves as a=
n=20
equivalent to ``yum update`` or ``apt-get upgrade``. You can simply say=20
``./bin/buildout``. Without the "-N" option it will fetch the latest versio=
n,=20
but the KGS guarantees that this will at most be a bug fix.

> In this case, generating the "meta egg" (or equivalent) should be
> unneeded: =A0that egg could just be managed within the KGS itself. =A0In 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).

Yep.

> Such a relase would be analogous to an installed Linux distribution,
> with update repositories pre-configured.

Exactely!

> Maintaining the KGS in this case is harder, and could probably use a
> little more tooling. =A0Once we have the tools, then tweaking them to
> allow generating a "frozen" release will be simple. =A0In 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).

Yep, I agree. The usefulness of tags other than for generating a full relea=
se=20
is questionable in my opinion, but I still agree with your ananlisys. :-)

Regards,
Stephan
=2D-=20
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training