[Grok-dev] how to manage the versions files, a plan
Martijn Faassen
faassen at startifact.com
Thu Feb 25 17:34:42 EST 2010
Hi there,
JW's notes surrounding the release got me thinking...
In Grok 1.1, we're going to have to deal with a number of versions files:
* ztk.cfg
* zopeapp.cfg
(both managed in the zopetoolkit)
* grok.cfg
* grok-ecosystem.cfg
(both managed in the groktoolkit)
I think we have some issues in grok.cfg and grok-ecosystem.cfg: they
both contain a [buildout] section. grok.cfg in turn *extends* ztk.cfg
and zopeapp.cfg.
I think that should be changed - instead, grok.cfg and
grok-ecosystem.cfg turn into pure files indicating versions and
containing helpful information for mr.developer. When we want to test
grok.cfg, we extend the *buildout.cfg* in grokproject with ztk.cfg and
zopeapp.cfg as well. We're not reusing that buildout.cfg, so we can do
whatever we like there (including allow-picked-versions set to false,
which we already do).
In the past, grokproject would install a versions.cfg into the Grok
project. This is downloaded from grok.zope.org/releaseinfo. grokproject
would add a few versions as well itself.
I think this is too dynamic and obscures the origins of these files,
especially now that we have some many. Instead, I think we should do the
following:
We adjust the releaseinfo structure, using subdirectories. So, we'll have a:
grok.zope.org/releaseinfo/1.1
In this subdirectory, we place a copy of ztk.cfg, zopeapp.cfg, grok.cfg
and grok-ecosystem.cfg that we know are right for that version of Grok.
Then when grokproject creates a project:
* downloads those files from the appropriate releaseinfo. The simplest
approach would be to download *all* .cfg files that are found there,
that way we can easily change what we ship later.
* installs those files into the grok project it creates. Perhaps it puts
a comment line in them to talk about their origins, but it shouldn't do
anything else.
* creates a buildout.cfg which extends all of these files.
What to do with those (hopefully very few) versions that *grokproject*
locks down itself? I think we should ship those with grokproject as a
grokproject.cfg, and grokproject can install a grokproject.cfg as well,
and add it to the buildout.cfg as well.
What do people think? Does this sound like a good idea? Any folks
interested in adjusting grokproject to work this way?
As to release planning. I don't think we should stop Grok 1.1's release
for this, let's just proceed with this. But if people think this is a
good idea, let's try to proceed with this quickly. We could for instance
produce a Grok 1.1.x release that can work with a newer grokproject. And
how will we deal with backwards compatibility?
Regards,
Martijn
More information about the Grok-dev
mailing list