Hey, Tres Seaver wrote: [snip]
I expect to see Zope2 trunk move to using the ZTK versions list quite soon: more than that, I'm willing to to the work to see that it happens (verifying that everything passes / works with the change), and give Hanno the patch to make it so, assuming he doesn't get around to it.
Cool. That's good to hear and something I really need to hear. :) I think you'll mostly be giving the ztk.cfg a patch to make it so, as Zope 2's list is ahead with a lot of mostly bugfix versions.
I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them.
If the release manager group gets consensus quickly on how their projects' interests align in the ZTK, then the fork can go away. Until then, pushing changes into the ZTK without consulting those projects' needs is premature.
Yes, such a change without such consultation was what created the problem in december. But that was a structural change of definition -- what is *in* the ZTK, not one of which releases were in the ZTK. It had something to do with letting the last zope.app.* dependency go from the cluster of zope.* packages. I'll note a short version list is not needed in order to feel that you're shrinking dependencies. I've been using depgraph for that. I will admit though that the longer the version list that is tested, the slower the tests and buildout run, of course, so that may be a concern for some (but how heavy should it weigh?). Could be something for the release managers to flesh out the balance between things. We haven't had the opportunity to have conflicts about specific releases yet ("I want zope.interface 4.3!" "no! 4.5!"). I think it's not a very big issue until someone starts doing a big dependency refactoring again - but that again is a structural issue, not a version issue. Regards, Martijn