I have a suggestion for a pinned package here but don't know exactly how this file is generated since I'm not a core developer. Can anyone give me directions?
What's your suggestion?
Those versions.cfg are a result of all the version pins required for all the eggs included in Plone.
This file is part of buildout.coredev. It is carefully crafted by the core developers. Any changes are made on a branch, which is tested via our jenkins.plone.org CI before it gets merged. Our Release Manager takes this file, checks it and copies it as part of the release.
IOW: Best, open an issue at https://github.com/plone/buildout.coredev/issues
The idea was to pin coverage: we have a bunch of Plone 4.3.x buildouts that need to pin it in [versions], so we thought, what about pinning in Plone http://dist.plone.org/release/4.3-latest/versions.cfg since the Plone folks pin it at http://dist.plone.org/release/5.0-latest/versions.cfg?
But I just checked and Plone 4.3.11 was released in 2016-08-15, with coverage being pinned in 2016-08-23 in https://github.com/plone/buildout.coredev/commit/e34dff9278c27e1f9ee89dfde1b0ad7499d9acf8 and again in https://github.com/plone/buildout.coredev/commit/7216029c6d5bf6fe9a0d44ce9784387808c620c3, so an issue is not needed since these versions will be available when a 4.3.12 release is made, right?
I don't remember why, but I think @mauritsvanrees pinned that different on purpose.
As long as you think https://github.com/plone/buildout.coredev/blob/4.3/versions.cfg has the correct version, it should show up fine once a Plone 4.3.12 release is made.
There's information here as well
We think this would be a nice addition to the versions.cfg file, but feel free to adopt or not this idea.