Greg Ward writes:
control freaks (me, Fred, and Konrad -- at least you two said you agree ... So: do any of you object to the above characterizations? I'd be
Greg, I can live with being a control freak; I hear this at home, too. ;) As far as the relationship with the rest of the distutils deliverables is concerned, there's a lot which is not related to the versioning issue, and there's no reason to let versioning delay other aspects of the project. All of the build/install/package code is independent of versioning. Versioning is important with regard to dependencies, both for dependency declarations for a package and availability analysis for locating dependency implementations. For this, some sort of reqiures/ provides model with version comparisons may be appropriate. As far as this goes, comparability of version numbers is more important than a specific scheme, so I'm inclined to accept that multiple versioning "schemes" be possible and have each be identifiable by name. A default that is somewhere between the "control freak" model and Greg Stein's variant should be fairly usable. Mark Hammond's "build number" approach seems to fit the syntactic model just fine; he's only using the first number, and it can get large. But that's ok for our immediate purposes, and compatibility analysis will probably require explicit statements of compatibility of various aspects (API, back-end data, whatever makes sense for each) on a per-release basis anyway. Using a requires/provides model allows each package to "provide" a number of "aspects" which can be independently versioned, as well. So each data format or API can be versioned independently. My frobnitz package can then do the following: requires xml-omnibus-package 0.6 provides frobnitz-data 1.0 provides frobnitz-API 1.0 provides frobnitz-API 1.1 -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191