[Zope-dev] the notion of a "next" in KGS

[Martijn Faassen]

Hi there,

During the post-Pycon sprint Hanno made me aware of a tool called 
mr.developer. This tool allows you to easily turn a particular package 
in your buildout into one you want to hack on, without you having to 
know where to check it out from.

mr.developer has a concept of "next" (Plone-next). Given a release of 
Plone, it needs to find out where the packages live in a version control 
system, and whether the next version is the trunk or a branch.

During the Grok sprint in late january when z3c.recipe.compattest was 
developed we ran into the same issue. We want to run compattests against 
some released set of versions, but also against all development 
versions. We took a shortcut there and just "guess" that all packages in 
the Zope Framework live on svn.zope.org and are the trunks. This is 
hardly ideal.

During the Pycon sprint Hanno also worked on a buildout recipe to draw 
dependency graphs: z3c.recipe.depgraph. We want to be able to draw the 
dependency graph of a selected set of versions, but we also want to be 
able to draw the dependency graph of all development versions.

So we have three tools that need this concept. This implies to me we 
need to expand the notion of KGS. (where I take it in the broad sense 
where we are talking about a known good set of something; Zope 2, Zope 
3, Zope Framework, Grok, etc).

The abstract notion of KGS currently is has these two fields (per 
package part of the KGS):

[pypi package name] [version]

If we are to expand this with a "next" notion, it would become like this:

[pypi package name] [version] [svn URL]

The svn url contains full information about where to check out the next 
version of the package. If we want to support alternate version control 
systems, we'd need to expand that, though I hope that all alternate 
version control systems have a notion of a URL to point to a version.

Once we have this extra information, we can publish it. Currently KGS 
exports the known versions list as a buildout versions section 
compatible list. We can't put the SVN URL in there. But we could also 
export another file per KGS release that contained the package name and 
the SVN URL. I believe mr.developer takes that kind of information. Once 
we have that, we can then adjust our tools to make use of this extra 
information.

Opinions? People who want to implement this?

Regards,

Martijn