[Grok-dev] how to manage the versions files, a plan

[Martijn Faassen]

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