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:
> = 3.6.7
> = 3.9.0
> zope.error = 3.7.0
> zope.location = 3.7.0
> = 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, 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?



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to