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

[Leonardo Rochael Almeida]

Sorry, this was supposed to go to the whole list, not just Martijn

On Thu, Feb 25, 2010 at 20:59, Leonardo Rochael Almeida
<leorochael at gmail.com> wrote:
> Wild idea...
>
> We should set a group of comments or settings in the generated
> buildout.cfg that contain a machine-readable location of the original
> urls for the various .cfg files. Then have grokproject generate a
> bin/grok-update script that downloads these files from the indicated
> locations.
>
> This way if a new release comes out and the user wants to upgrade his
> grok buildout, he can just run bin/grok-update, eventually adjusting
> the comments to indicate he wishes to download a specific version.
>
> Cheers, Leo
>
> On Thu, Feb 25, 2010 at 19:34, Martijn Faassen <faassen at startifact.com> wrote:
>> 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
>>
>> _______________________________________________
>> Grok-dev mailing list
>> Grok-dev at zope.org
>> https://mail.zope.org/mailman/listinfo/grok-dev
>>
>