ZTK meeting - 2010-05-06¶

Attendance¶

ccomb, j-w, hannosch

Communication

Our role

We see ourselves as representatives of communities that make use of the ZTK
We should ensure stable releases of the ZTK, which are useful to our projects not more and not less

Release outcome

Should produce a http://download.zope.org/ztk/release/1.1 with a ztk.cfg in it and a the zopeapp.cfg (for as long as it exists) in it.
Nice to have: an index (for easy_install people)
Should have some documentation site stating changes (http://docs.zope.org/zopetoolkit/releases/overview-trunk.html)

Release policies

At first manual releases (x.y.Z), automate the process to generate the bugfix releases later. We need to make sure to release only versions sets for which all tests passed.
ztk x.y.z. releases, stable package list per release
a ztk minor release per month would be ok
a ztk major release “when one of the consumers projects needs it”.
backward compatibility breaking only happens in X.y.z that means, if we have a zope.component 4.0.0, it will be part of ZTK 2.0 or 3.0
generally upstream releases happen in a 6-12 month interval, so the same timeline makes sense for ZTK releases

We want 64bit Linux and Windows tests for the ZTK. j-w is bugging janjaap to create those. Maybe contact ccomb for adding slaves to “afpy” [j-w]
Make sure we have a buildbot testing the ZTK releases (and not SVN) [ccomb]

Look at Tres’s list of packages in all three frameworks, decide on a way to drop things from the initial ZTK set and on a process for the future.
Look at and update http://docs.zope.org/zopetoolkit/about/coreextra.html for adding/removing policies, probably have a deprecated.cfg file
Decide on process for new feature versions and the process for going from 1.1.0 alpha to a final

2010-05-18, 14:00 to 15:00 UTC before the zope-dev meeting, in #zope