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