Got zc.recipe.cmmi 2.0.0.
The constraint, 1.7.1, is not consistent with the requirement, 'zc.buildout>=2.9.4'.
While:
Installing.
Getting section node.
Initializing section node.
Installing recipe gp.recipe.node.
Error: Bad constraint 1.7.1 zc.buildout>=2.9.4
As you can see, it asks for zc.buildout at least 2.9.4, which is a version released yesterday. We're pinning locally to 1.3.6, but would like a more generic approach. Will you be pinning this to coredev, unified and buildout.plonetest?
We're pinning it already. But a lot of buildouts in the Plone world that don't have for example zc.buildout = in a [versions] section and that uses gc.recipe.node without this pin will break, so we think that having it in a more upstream cfg definition as we suggested will ease the pain specially for inexperienced users since zc.recipe.cmmi isn't usually a direct dependency.
Just because a new package version can cause a buildout error, is for me no reason to suddenly start adding it the core versions. The core versions should only contain version pins for packages actually used in core. Exceptions certainly can be and have been made, for example the plone.app.contenttypes related pins in Plone 4.3.
We have not added a pin for Products.PloneFormGen either, but the latest release is for Plone 5 only, so will break Plone 4.3 builds too.
I guess I can imagine a pin for zc.recipe.cmmi. But I don't see it used in any of the community packages I have checked out, except for plone.recipe.varnish. But if you are using varnish in a buildout, then it is meant for production, and then you should have either pinned all versions yourself, or are prepared to handle breakage.
Since buildout.plonetest uses it in qa.cfg for the node part, your PR there seems fine.
We thought that gc.recipe.node would be used extensively in the future because of node, that's why we asked for official pins. But indeed, once that happens, maybe it'll be zc.buildout that will be updated, not needing to pin zc.recipe.cmmi.