[Zope-dev] Updating the ZTK KGS
Martijn Faassen
faassen at startifact.com
Mon Oct 5 08:22:35 EDT 2009
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
More information about the Zope-Dev
mailing list