Jim Fulton wrote:
> On Fri, Aug 14, 2009 at 1:03 PM, Chris Withers<ch...@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.
+1. No ranges. If you want to update a version in your own app's
buildout you should be able to override it, of course, but the KGS
should be a fixed point.
> 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.
That sounds reasonable, as long as it is documented. I got confused at
first about the term 'test branch', but you just mean a non-maintenance
branch of a package to do some development on. The special thing is here
that we'd wait for the buildbot to do the testing on different platforms.
I wonder whether we couldn't use snakebite.org infrastructure for the
testing. I'd be good if someone could manually trigger a cross-platform
cross-interpreter test instead of having to wait for buildbots.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -