[Grok-dev] Existing project upgrade procedure

[Tim Cook]

BTW: I found this readme.html at
http://grok.zope.org/releaseinfo/readme.html (dated 27 Oct 2007)

The section on upgrading seems reasonable however the extends directive
is used in that example before the versions = versions

This is apparently before there was a versions.cfg and the [versions]
section was still in buildout.cfg

I'm not sure what I've learned from this except that there is a document
that did put some thought into the upgrade process.  But it was hiding
in a place and with a name that I hadn't found before. :-)

Cheers,
Tim



On Fri, 2009-05-22 at 08:57 -0300, Tim Cook wrote:
> With the various ideas presented and my own confusion about what
> actually goes on during the execution of:
> 
> python bootstrap.py or bin/buildout in an existing project
> 
> I would like to relate my understanding as a Grok newbie of sorts so
> that we can come up with procedures that other newbies can successfully
> follow. 
> 
> Do we need a versions.cfg?  From my understanding we do and should use
> this as the primary determination of which eggs are used.  
> 
> If the above is true then the suggestion:
> ===============================================================
> 1) In the [buildout] section of buildout.cfg, _after_ the line saying::
> 
>     versions = versions.cfg
> 
>   insert::
> 
>     extends = http://grok.zope.org/releaseinfo/grok-1.0a4.cfg
> 
>   This way you override any versions in versions.cfg.
> ==========================================================
> seems counter-intuitive.  Let's say that I started a project using
> grokproject when grok was a version 1.0a1 and in a few years we are at
> Grok version 6.2.  It is very likely that the existing versions.cfg is
> meaningless at this point because
> http://grok.zope.org/releaseinfo/grok-6.2.cfg is probably going to
> override everything in the existing versions.cfg.  We also have the
> section at the bottom of versions.cfg where 
> # Here we pin the recipes and other packages that are not in the
> # downloaded versions.cfg of grok
> 
> I'm not sure why this exists.  Shouldn't everything be in the
> releaseinfo/xxxx.cfg? For example; how will I know that 
> Paste = 1.7.2 should now be Paste = 2.1.3 in the future without running
> grokproject?
> It seems to me that there is too much dependence on grokproject alone.
> While it was wonderful to start my project this way, I don't think I
> should ever need it again on an evolving project.
> 
> Another question I have is why z3c.evalexception>=2.0 has a version in
> buildout.cfg and everything else is pinned in versions.cfg?
> 
> It seems to me that there should be a way to change one line/directive
> somewhere in buildout.cfg in an existing project that would point to the
> new version of grok's version.cfg.  Re run buildout and the upgrade
> would be performed.  Is this possible?
> 
> I do realize that we are working with alpha software and that most of
> this confusion is partly my lack of understanding as well as the
> parallel evolution of Grok and Grokproject.  
> 
> 
> Thanks for your feedback and corrections to my thoughts here. 
> 
> Cheers,
> Tim
> 
> 
> 
> 
> 
-- 
Timothy Cook, MSc
Health Informatics Research & Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook 
**************************************************************
*You may get my Public GPG key from  popular keyservers or   *
*from this link http://timothywayne.cook.googlepages.com/home*
**************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20090522/0d99ea7e/attachment.bin