Attempted summary of version number thread
I'm going to see if I can't make some sense out of the version-numbering thread of the last couple of days. First: if you've already said your two cents' worth in this thread, please don't chime in again. I think everyone has made their point quite clear. (However, if I misunderstood you and misrepresent you in the summaries below, a brief correction to the list would be appreciated.) It seems to me that there are four camps out there: the control freaks, the anarchists, the middle-of-the-roaders, and John Skaller. The control freaks (me, Fred, and Konrad -- at least you two said you agree with me!) are in favour of prescribing *syntax* for version numbers and *suggesting* semantics. The *proposed* syntax and semantics that I posted are up for debate, but at least three of us like the idea of imposing a little order on how version numbers look, and giving developers some general guidelines -- which they are free to ignore! -- about what they should mean. The anarchists are Greg Stein and Marc-Andre Lemburg; these two take a "live and let live" approach to version numbers. They seem to concede that some very light syntactic requirements are necessary, but want developers to be free to define their semantics however they like. (Or, Greg and Marc-Andre just want to write code to describe the existing multitude of version number systems.) I think Andrew Kuchling is the only middle-of-the-roader, and I might be saying that just because I know Andrew's a pretty relaxed guy and not prone to radical positions like anarchy. Anyways, he posted an anti-prescriptionist statement to the list right after my syntax and semantics proposal. Maybe Andrew is really our third anarchist. Finally, John Skaller is out on his own. As I read it, John has a much wider definition of "version" than I (or the others who've posted on the topic) do. Or maybe it's more accurate to say: I started this thread to talk about *version numbers*, and John is more concerned with software versions *in general* -- all the things that can't be expressed in a simple linear progression. So: do any of you object to the above characterizations? I'd be interested to hear the opinions of anyone outside the above six, especially if you feel there're more sides to this debate than "control freaks", "anarchists", and "John Skaller". (Gee, I hope John is back on the list -- mailman disabled him because of excessive bounces, and I'd hate for him to miss this. ;-) One possible way to resolve this is to provide a couple of standard classes to implement version numbering systems. I won't say any more in detail right now, because I don't want to start another heated debate. But think about it... Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward wrote:
I'm going to see if I can't make some sense out of the version-numbering thread of the last couple of days.
First: if you've already said your two cents' worth in this thread, please don't chime in again. I think everyone has made their point quite clear. (However, if I misunderstood you and misrepresent you in the summaries below, a brief correction to the list would be appreciated.)
...
The anarchists are Greg Stein and Marc-Andre Lemburg; these two take a "live and let live" approach to version numbers. They seem to concede that some very light syntactic requirements are necessary, but want developers to be free to define their semantics however they like. (Or, Greg and Marc-Andre just want to write code to describe the existing multitude of version number systems.)
I wouldn't describe myself as anarchist... realist is more like it ;-) We should get on with more important things than version numbers, IMHO, really. What's inside the package is important, not how it is named. And that information is quite well captured by the Trove meta records. ------------------------------------------------------------------- What I'd like to see is a way that automates the build process. Automating software updates is by far more complicated and should be deferred for now. BTW, Fredrik mentioned that building with VC++ on WinXX is doable with command line invocation only. Wouldn't that be a good start into unifying the make process on Unix and WinXX [what about Macs ?]. A WISE kind of installer for Unices wouldn't look bad either. Could be done using Tkinter or ncurses or simple text based dialogs: /home/sweet/home> ./setup.py PACKAGE FooBar Show version information ? [No] Show install guide ? [Yes] Which Browser should I use ? [netscape] ...netscape fires up and displays the install guide... Where do you want to install today ? [/usr/holidays/beach]
building... ok Should I run the test suite now ? [Yes] running tests... ok (output stored in FooBar.tests) Display install summary ? [No] Should I save your answers for future installations ? [Yes] saved to FooBar.installation
FooBar installed successfully. All this is doable and could even be fun... I suggest just hacking away at something like it and then abstracting all meaningful bits & pieces into nice distutils modules. PS: For the typical Unix freak we should also include a README pointing her to ./setup.py and maybe even a Makefile with all targets running ./setup.py using additional parameters, e.g. setup.py --make install, setup.py --make clean, etc. PPS: For the typical WinXX freak there'll have to be an install.bat of course ;-) PPPS: Don't know how the Macs do it... they probably just click on the icon :-) -- Marc-Andre Lemburg Y2000: 385 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : ---------------------------------------------------------
So: do any of you object to the above characterizations? I'd be interested to hear the opinions of anyone outside the above six, especially if you feel there're more sides to this debate
Well, you asked :-) Im definately on the side of the Anarchists. IMO, the "deliverables" from this SIG should be unobtrusive as possible, and should conform to _my_ wishes, rather than the other way around. For example, my Windows extensions use a simple "build number", and this is what I want to continue to use. My reasoning is simply that I make many incremental releases - its not a product per se. There is never a clear distinction between "versions" - what would "version 1" of my extensions be, or "version 2"? Further, it is never clear to me when my releases are "beta" - new features may not work completely as advertised, but core features are typically more stable than previous versions. This is almost certainly an artifcat of the volume of things in my single package - but that is the point - the way _I_ do things dont necessarily fit with the other version branding models being imposed. Of course, other things I have in mind _do_ fit better with some of the proposed schemes. So one size doesnt fit all, even just for me! If the deliverables require me to rework too many things, or shoehorn into a scheme that doesnt fit for me, I may simply not bother. Without presuming to speak for Marc and Greg, IMO, the message is clear - if some people on this SIG dont see it working for them, then the chances of it becoming truly general purpose to the wider community are slight. Just MHO (Mark Hammond's Opinion :-), of course! Mark.
the anarchists, the middle-of-the-roaders, and John Skaller. The control freaks (me, Fred, and Konrad -- at least you two said you agree with me!) are in favour of prescribing *syntax* for version numbers and *suggesting* semantics. The *proposed* syntax and semantics that I
Right, and it seems worth pointing out again why, or rather to what extent, the interpretation of version numbers should be unified. The criterion is that it must be clear both for human users and for installation programs 1) which of two versions is newer 2) if two versions are compatible, i.e. use the same APIs The first criterion could be met by any "reasonable" version numbering scheme, plus a package-specific routine for comparison, as has been pointed out by the "anarchists". But the second one is less obvious to realize. For the installation program, another package-supplied routine would be sufficient, but it should also be clear for a normal user whether version 1.2.3 is merely a bug-fix update to 1.1.0 or uses a non-compatible API. Another distinction that matters for the user is whether code is production level or experimental. Within these limits I am willing to leave all the freedom people want, such as whether to start at 0 or at 1. So perhaps the following scheme might be acceptable: Version numbers start with an API version number, then any combination of letters and punctuation that is likely to make sense to a human reader, followed by an optional "alpha" or "beta" indicator. The first number would change only if a package cannot be used as a drop-in replacement for its predecessors. Is that something the "anarchists" could agree on? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
Quoth Konrad Hinsen, on 14 December 1998:
The criterion is that it must be clear both for human users and for installation programs 1) which of two versions is newer 2) if two versions are compatible, i.e. use the same APIs
OK, just to keep everyone on their toes, I'm going to take the anarchists' side here. I have said several times that I am against *imposing* semantics of version numbering, and if I read Konrad right here that's what he's suggesting: a certain part of the version number implies "API version". I don't think this'll work, and not just because Greg and Mark and Marc-Andre (and probably lots of other people) don't like it. I do kind of like it, being a control-freak myself, but I don't think it'll work! Most developers just don't think *that* carefully about what their version number means. Or they might think carefully about it, but come to different conclusions: if you completely rewrite your software, you might feel that justifies bumping from 1.x to 2.0 -- even with full API compatability. We simply cannot mandate these sorts of details on something like the world of all Python modules. Perhaps an "API version number" belongs in the package meta-data, along with the multitude of variables that John Skaller considers part of the "version" (again, I think John is talking about something much bigger than "version numbers", and I think what he's talking about can be considered package meta-data). While I think it's a worthy goal to try to automatically handle all forms of module inter-dependency, I also think it's a vast swamp with no discernible exit. The goals for the distutils should be modest: be able to compare version numbers and express module dependencies in terms of version numbers. Expressing compatability on the many axes John proposes, plus the "API version", would be very difficult. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
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.
participants (5)
-
Fred L. Drake -
Greg Ward -
Konrad Hinsen -
M.-A. Lemburg -
Mark Hammond