On Fri, Aug 14, 2009 at 1:03 PM, Chris Withers<chris@simplistix.co.uk> wrote: ...
One question, and I know I'm late in on this so feel free to point me at previous discussions, but say the KGS uses some.egg 1.0.0, a bug gets fixed in some.egg and 1.0.1 is released. Does a whole new KGS need to be cut or is there some process for testing and supporting, says, 1.0.0 <= some.egg < 1.1.0 ?
The KGS should not support ranges IMO. It should be updated as new versions are released. It should also be tagged when updated. We need to agree on the the process for updating the ZTK KGS. Here's a rough sketch of what I think we need. - We need to create a test branch. - When a developer wants to update a project version, they check out the test branch, make a local version change and run the tests. If the tests pass the check the change into the test branch. - We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6. - When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested. Thoughts? BTW, in my zopetoolkit dev branch, I've created a kgs directory to hold the ztk.cfg file and a ztk kgs buildout. If no one complains about this soon, I'll commit this to the trunk and this will become the official home of this info until we decide differently. Jim -- Jim Fulton