Thomas Lotze wrote:
Having worked on and released new versions of a few ZTK packages recently, I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as there doesn't seem to be an agreed process about this and in an attempt not to step on anyone's toes, I'd like to ask first whether it is OK for any developer to modify the versions listed in ztk.cfg (provided that all relevant tests are passing, of course). I'd currently like to update the following packages:
zope.app.apidoc = 3.6.7 zope.app.publication = 3.9.0 zope.error = 3.7.0 zope.location = 3.7.0 zope.site = 3.7.0 zope.traversing = 3.8.0
Thanks for bringing this up. There's indeed currently no agreed-upon process. Jim a while ago was proposing a rather heavy staging process where the trunk can only be changed if a staged branch passed all tests on all platforms (and Python versions) as run by a buildbot. We don't have the infrastructure for this yet and Christian Theune and I were wondering whether this is needed. An alternative process would be to only *release* the ZTK after the compat tests run on all platforms as shown by the buildbot. We do have infrastructure for that. So I'd propose the following development process: * developers can change the version numbers in the ZTK * if the compattests all run, they can check in And then for releases: * we determine we want to make a release of the ZTK * if the buildbot reports it all works on all platforms * we verify there have been no further modifications since then * we can release * what does a release look like exactly? We should at least have a documentation release sitting somewhere on docs.zope.org, with the release number in the URL. The 'current' URL should also point to this documentation. Along with this we should also publish the lists of versions for reuse. How? Regards, Martijn