Phew, just in time for Christmas. Get your copy today from
http://www.python.org/sigs/distutils-sig/
Many bugs fixed in this one. Works great on Linux and Solaris; I didn't hear back from anyone about whether it works on Windows, so I'm taking a chance.
Here's the entry from the CHANGES file:
* changes to command-line semantics: - verbose mode is now the default - added help options (and generation of help text), both globally and for each command - better usage message * anywhere that accepts/requires a list of strings now also accepts a tuple of strings (but lists of tuples still have to be lists -- there are limits) * fixes to "build_py" command - explicitly ensure that the setup script (sys.argv[0]) is never included with the modules to be installed - do *not* preserve file mode when copying .py files into the build tree (was preserving 0444 permissions [read-only], which caused subsequent installation of the same module distribution to fail) - several silly bugs that showed up when building simple, non-packagized distributions * fixes to the "dist" command - correct behaviour with filename pattern regexes - don't blow up if MANIFEST missing, just warn and carry on - blow away "distribution" tree after making archive file(s)
Enjoy! Thanks to everyone who spotted bugs (especially Guido for a very useful checklist).
Greg
On Wed, 15 Dec 1999, Greg Ward wrote:
Phew, just in time for Christmas. Get your copy today from
http://www.python.org/sigs/distutils-sig/Many bugs fixed in this one. Works great on Linux and Solaris; I didn't hear back from anyone about whether it works on Windows, so I'm taking a chance.
<rant>
Who cares whether it is chancy or not?
This is a symptom that I've seen from many people. "Oh! I can't release yet... it might break." Or another favorite "Here is a pre-release, please test it and then I'll make a real release."
Screw that. Release a version. If that breaks, then release another. This whole tentative thing just slows everything down. Holding back releases doesn't really buy a person anything.
I remember somebody on python-list didn't want to release some code because they didn't "clean it up" and/or document it. Six months later, they still hadn't released the code -- meaning nobody got *any* advantage out of that code. Even if you release crap, then somebody may still be able to use it. Maybe they can even help you fix it up. But the notion of "well, I need to do X before sending out a copy" often translates to "I'll never send out a copy."
</rant>
Cheers, -g
On 15 December 1999, Greg Stein said:
Who cares whether it is chancy or not?
This is a symptom that I've seen from many people. "Oh! I can't release yet... it might break." Or another favorite "Here is a pre-release, please test it and then I'll make a real release."
In my own defense, I think I like the code snapshot followed by a real release a few days later. That shows the world that things are happening, and gives me time to take care of the bureaucracy of making a release: make sure everything's checked in and tagged, update the changelog, update the readme, update the web pages, and so forth.
Of course my self-imposed bureaucracy *does* slow down making releases -- I would have a hard time putting out new versions every other day because I insist on having a readable, grammatical, up-to-date README file, and I am really keen on having everything under CVS control and appropriately tagged. These are the little things that make trying out new software a lot easier on people; I for one am sick to death of moderately good software that is hobbled by a lousy, out-of-date README or poorly-written documentation. I prefer to take a few hours more and put out quality information as well as quality code.
IOW, yes: release early and release often. But how early and how often are matters of personal style, and not everyone can proceed at a Linus-esque breakneck pace of new releases every couple of days.
Greg
On Thu, 16 Dec 1999, Greg Ward wrote:
On 15 December 1999, Greg Stein said:
Who cares whether it is chancy or not?
This is a symptom that I've seen from many people. "Oh! I can't release yet... it might break." Or another favorite "Here is a pre-release, please test it and then I'll make a real release."
In my own defense, I think I like the code snapshot followed by a real
:-) ... it wasn't truly aimed at you, which is why I munged the To: to be the SIG rather than you :-) But hey... we can talk about you if you'd like... hehe.
release a few days later. That shows the world that things are happening, and gives me time to take care of the bureaucracy of making a release: make sure everything's checked in and tagged, update the changelog, update the readme, update the web pages, and so forth.
"happening" is also shown thru multiple releases. And yes, I agree: there is a "release tax" that needs to be paid. I think you get used it to it, though, if you release often. I know that mod_dav releases are pretty cheap for me nowadays... there is a "rhythm" you might say.
Of course my self-imposed bureaucracy *does* slow down making releases -- I would have a hard time putting out new versions every other day because I insist on having a readable, grammatical, up-to-date README file, and I am really keen on having everything under CVS control and appropriately tagged. These are the little things that make trying out new software a lot easier on people; I for one am sick to death of moderately good software that is hobbled by a lousy, out-of-date README or poorly-written documentation. I prefer to take a few hours more and put out quality information as well as quality code.
I understand. I would counter that some people would still find it useful, even if the README is out of date, or there are some tweaky problems in it. Note that other people might submit README fixes if it bugs them too much.
IOW, yes: release early and release often. But how early and how often are matters of personal style, and not everyone can proceed at a Linus-esque breakneck pace of new releases every couple of days.
Sure. But I'll reserve the right to prod people here and there when they start to look all bottled up :-)
Cheers, -g
<rant>
Who cares whether it is chancy or not?
This is a symptom that I've seen from many people. "Oh! I can't release yet... it might break." Or another favorite "Here is a pre-release, please test it and then I'll make a real release."
Screw that. Release a version. If that breaks, then release another. This whole tentative thing just slows everything down. Holding back releases doesn't really buy a person anything.
I remember somebody on python-list didn't want to release some code because they didn't "clean it up" and/or document it. Six months later, they still hadn't released the code -- meaning nobody got *any* advantage out of that code. Even if you release crap, then somebody may still be able to use it. Maybe they can even help you fix it up. But the notion of "well, I need to do X before sending out a copy" often translates to "I'll never send out a copy."
</rant>
I realize it's just a rant. In this case (distutils) your advice is correct. (I usually paraphrase it as "release early, release often".)
However there are other situations, like core Python itself, where it's really useful to have stable releases -- if only for those users who won't touch anything with "beta" in its name. I still hear from people who haven't upgraded to 1.5.2.
I wonder if perhaps for those cases (where there's a demand for stable releases) some other strategy could be used? Such as labeling releases "stable" after the fact? Or what Linus seems to do with the Linux kernel (even = stable, odd = development; or was it the other way around?).
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)
Guido van Rossum writes:
who won't touch anything with "beta" in its name. I still hear from people who haven't upgraded to 1.5.2.
You mean not everyone works off the CVS version? Sheesh, I thought the version number was just legacy... How can anyone live without string methods? ;)
I wonder if perhaps for those cases (where there's a demand for stable releases) some other strategy could be used? Such as labeling releases "stable" after the fact? Or what Linus seems to do with the Linux kernel (even = stable, odd = development; or was it the other way around?).
You have the even/odd thing right. The problem with it is that it really requires just as much planning as the release strategy you're already using, it's just that the labels are semantically loaded without being "syntactically" distinct. I don't see that it's an especially good way of doing things in general, however well it's worked for the Linux kernel community. (Note that I'm not saying it's a bad way, just that the benefits are not very clear.) I think there are a few reasonable approaches to the stable/devel dichotomy:
- Use labels like "alpha", "beta", "release candidate", etc., possibly shortened to "a", "b", "rc", or whatever, to indicate various levels of stability in development/test releases. Use two- or three-part numeric designations for "stable" releases. This is exactly what you've been doing with Python itself, and is what appears to be most common, at least in the Unix world.
- Use either a "build number" approach similar to that used by PythonWin, and then declare things "stable" by re-releasing with a new number and only README/documentation changes and declaring stability as part of the release announcement. Multi-part version numbers may still be useful here, but maybe no more than two parts. I'd expect the first part to grow a little faster, so the distinction between "Python" and "Python 2" would probably have to be made in a different way ("Python++" ;).
- Use "build number" or multipart numeric versions, and declare stability after the fact. I'm much less enamored of this, simply because I'd like to see the stability indication as part of the release. This is probably the worst possible case for people who don't follow the language news much at all (a group which will probably grow the most as Python penetration increases). So don't use this one.
Essentially, I don't see any compelling reason to change the approach to versioning; anything with a version number of less than one should be considered preliminary (Rainer Menzner always included "beta" as part of pre-1.0 release numbers, just to be completely clear about the status.) But I agree, more frequent releases of the distutils package would be useful. Part of that is a matter of disseminating bug fixes and feature improvements, but part of it is also maintaining interest and visibility for the project. Having an alpha or beta isn't any good if no one is interested in it.
-Fred
-- Fred L. Drake, Jr. fdrake@acm.org Corporation for National Research Initiatives
On Thu, 16 Dec 1999, Guido van Rossum wrote:
... I realize it's just a rant. In this case (distutils) your advice is correct. (I usually paraphrase it as "release early, release often".)
True. I prefer that phrase, too, but I used it on JimA earlier in the day or the previous day. I didn't want to sound like a broken record :-). But that is why I moved into <rant> mode... it seems like the mindset was spreading :-) I've railed at AMK for it, too :-), when he was talking about 0.5.1pre1 or whatever, rather than just releasing 0.5.1 and doing an 0.5.2 if there was a problem.
However there are other situations, like core Python itself, where it's really useful to have stable releases -- if only for those users who won't touch anything with "beta" in its name. I still hear from people who haven't upgraded to 1.5.2.
But this doesn't explain why there isn't a 1.5.3b1, 1.5.3b2, etc. Or 1.6.0a1 or whatever (maybe "d" or "r" for dev release, as opposed to alpha).
There are some people would like the releases rather than using CVS. Some people can't even use CVS because of firewall issues. Of course, an alternative is snapshot-tarballs of the CVS repository. But a snapshot could *really* be broken; something like 1.6.0d1 says "well, it's a development release, but I've hit a good point between some changes."
I wonder if perhaps for those cases (where there's a demand for stable releases) some other strategy could be used? Such as labeling releases "stable" after the fact? Or what Linus seems to do with the Linux kernel (even = stable, odd = development; or was it the other way around?).
Yes: even are stable (e.g. 1.0, 1.2, 2.0, 2.2). The odd numbers are for development. Linus is currently working 2.3.x, but declared in the past couple days that things will be wrapping up to move towards 2.4. Once he thinks it is ready, he'll start off with 2.4.0pre1, pre2, pre3... At some point the "pre" suffix will drop and 2.4.0 will be released.
You might have a bit of problem using that mechanism since the current stable release is 1.5 :-). Once 1.6 hits the street, then you could start doing 1.9 releases (dev) and shift to 2.0 once it is "stable".
Cheers, -g
>> I wonder if perhaps for those cases (where there's a demand for >> stable releases) some other strategy could be used? Such as >> labeling releases "stable" after the fact? Or what Linus seems >> to do with the Linux kernel (even = stable, odd = development; >> or was it the other way around?).
I really dislike the odd/even distinction for exactly this reason.
-Barry
>>> Or what Linus seems to do with the Linux kernel (even = stable, odd >>> = development; or was it the other way around?).
BAW> I really dislike the odd/even distinction for exactly this reason.
It's one saving grace is that it is a uniform format. There are no "optional" tokens like "pre", "alpha", "beta", etc for the most part.
To remember which way it is, I find it useful to execute "uname -r", check the second digit, then look down at my shirt for a pocket protector. The two pieces of information together work for me. I currently get "2.2.13-4mdk" from uname. I don't even have a pocket, let alone a pocket protector, so even numbers must be stable releases...
;-)
Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented...
"SM" == Skip Montanaro skip@mojam.com writes:
SM> To remember which way it is, I find it useful to execute SM> "uname -r", check the second digit, then look down at my shirt SM> for a pocket protector. The two pieces of information SM> together work for me. I currently get "2.2.13-4mdk" from SM> uname. I don't even have a pocket, let alone a pocket SM> protector, so even numbers must be stable releases...
What do you do if it's the second Thursday after the full moon, and the local hockey team has just skated to a 3-3 tie?
-Barry
-
Barry A. Warsaw -
Fred L. Drake, Jr. -
Greg Stein -
Greg Ward -
Guido van Rossum -
Skip Montanaro