In case you haven't heard through some other
channel already, Twisted 8
is out.
In addition to numerous fixes and features, this release also includes a new
release system for Twisted itself; this (hopefully) means that we won't have
another year-long release drought. We're planning to do another
release in less than 3 months.
This means that new Twisted features will be available faster, but it also
means that if you're writing some software that uses Twisted, upgrade
now! We try very hard to make sure that each new release is
mostly
compatible with the one that comes before it, so that your upgrade
should be painless. Especially if you have good unit tests.
However, this compatibility doesn't extend infinitely. There are at
least a few twisted developers who would
really like to drop some of our years of
accumulated cruft and break compatibility with older versions.
If you upgrade now, your migration process will be gradually fixing a few
deprecation warnings. If you wait for 3 or 4 more minor releases,
upgrading all at once will mean that anything which has changed will start
off broken, and your tests might not even run until you've fixed a bunch of
things.
Of course, by "will", I mean "should" - we're not perfect, but we'll fix
upgrade issues in micro releases if you find them and report them.
I (and others) have been working on him for years to release this stuff as open source, and he's finally done it!
Go check it out the Multiverse 3D trac site, and get the code!
Do it!
Do it now!
(and then start submitting patches to get its persistence layer ported back over to Axiom because I told Mike not to block the release on that but it should totally be using Axiom and he only switched away from it because he didn't understand quite how it worked...)
Some library maintainers, when faced with the impending incompatible changes
in Py3K, decide that it's time to burn their library down and start over
with a new, incompatible version. "Python is changing", they say, "so
people are going to have to do a bunch of maintenance anyway. What a
great opportunity to force them to do all that maintenance that they should
be doing for our library too!"
I'm saying it's wrong. But don't take my word for it: Guido says it's wrong. Before it became cool to do it, Martijn Faassen was saying it was wrong.
Guido didn't just blog that it was wrong, though. He was so concerned that this message get out publicly that he repeated himself in a mailing list message to python-dev to make sure that people who don't read blogs would get the message.
This might strike some library maintainers as unfair. If Py3K is just breaking compatibility, why can't you?
First of all, even if Py3K were really "just breaking compatibility", there is still the issue of careful timing. You should read Guido's post and understand Ima Lumberjack's plight; he explains it exactly as I would. When your users are doing maintenance to upgrade something, they only want to upgrade one thing, so they know what's going wrong when they encounter problems. And if you're making incompatible changes, they will encounter problems, regardless of how cool and well-documented your new API is.
But, if you look closely, you will find that there's another reason that your library doesn't play by the same rules that Py3K does. It's because Py3K is actually doing a lot more than just breaking compatibility.
I've been a critic of this effort in the past (and I still occasionally grumble about a thing or two) but the bottom line is that the core Python team is not just willy-nilly breaking stuff. Let me enumerate the huge amount of work they're doing to make sure that people can have a reasonable migration experience to Python 3:
So, if you answered "yes" to all four of those questions — you still don't have the same excuse that Python does, because their dependencies are not changing incompatibly. So don't do it. But if you were thinking about breaking compatibility at the same time as a dependency, then you probably didn't.
Of course, you can drop deprecated stuff and break compatibility if your user community will tolerate that. Just don't do it in the same version where you decide to support Py3K. Users should have the ability to get a compatible version that will work in 2.x and 3.x so that when they translate their own source code, they don't have to learn new methods right at that moment.
I'm saying it's wrong. But don't take my word for it: Guido says it's wrong. Before it became cool to do it, Martijn Faassen was saying it was wrong.
Guido didn't just blog that it was wrong, though. He was so concerned that this message get out publicly that he repeated himself in a mailing list message to python-dev to make sure that people who don't read blogs would get the message.
This might strike some library maintainers as unfair. If Py3K is just breaking compatibility, why can't you?
First of all, even if Py3K were really "just breaking compatibility", there is still the issue of careful timing. You should read Guido's post and understand Ima Lumberjack's plight; he explains it exactly as I would. When your users are doing maintenance to upgrade something, they only want to upgrade one thing, so they know what's going wrong when they encounter problems. And if you're making incompatible changes, they will encounter problems, regardless of how cool and well-documented your new API is.
But, if you look closely, you will find that there's another reason that your library doesn't play by the same rules that Py3K does. It's because Py3K is actually doing a lot more than just breaking compatibility.
I've been a critic of this effort in the past (and I still occasionally grumble about a thing or two) but the bottom line is that the core Python team is not just willy-nilly breaking stuff. Let me enumerate the huge amount of work they're doing to make sure that people can have a reasonable migration experience to Python 3:
- The Python core team have written and are maintaining a source-to-source translation tool to assist in the transition. Does your compatibility-breaking project have source-to-source translation, or in fact any tool support for migrating between different versions of the library?
- The Python core team are developing a compatible backport of 99% of
their features: Python 2.6 is effectively "python 3 lite"; you don't need
to upgrade all the way to the incompatible version to get a lot of the new
features. Does your compatibility-breaking project include a (at
least mostly) compatible backport of all of your new features to an
actively developed, "older" version?
- The Python core team is providing long-term support for the previous version so that people can migrate at their own pace and not be left out in the cold. Is your compatibility-breaking project planning to provide a decade worth of bugfixes, security patches, and feature backports to your older versions?
- The Python core team is providing comprehensive deprecation warnings explaining each new feature, and how you get there from the old feature. Is your project going to provide documentation like that?
So, if you answered "yes" to all four of those questions — you still don't have the same excuse that Python does, because their dependencies are not changing incompatibly. So don't do it. But if you were thinking about breaking compatibility at the same time as a dependency, then you probably didn't.
Of course, you can drop deprecated stuff and break compatibility if your user community will tolerate that. Just don't do it in the same version where you decide to support Py3K. Users should have the ability to get a compatible version that will work in 2.x and 3.x so that when they translate their own source code, they don't have to learn new methods right at that moment.
Summary: PyCon 2008 was a great time. I didn't go to a single talk,
except a few of the keynotes; I spent pretty much my entire time
cross-pollinating with other projects and plugging the until-recently-secret
Twisted Software Foundation - our nickname for the Twisted project's
membership of the Software Freedom Conservancy (TSF/SFC).
I briefly addressed the audience (of over one thousand python users) to kick off the TSF announcement, mostly to introduce Duncan. However, someone managed to snap a picture of me that I think captured the feeling of awe that we've come so far in such a relatively short time.
I spoke to about 400 people at the conference, and I have a lot to follow up on. I also have a day job, 阿as those of you that I spoke to about Mantissa rather than Twisted know ;-).
If I talked to you about something at the conference, please don't hesitate to send me email reminding me about it. Ideally, send me email reminding me in one to three weeks. I have almost 1000 unread emails right now and while I try to be rigorous about using some unique features of Divmod's mail system to make sure I reply to each one, there is a certain volume of communication which no tool can help me cope with.
My first priority is blogging about interesting aspects of the conference in the next few days, before I've forgotten.
I briefly addressed the audience (of over one thousand python users) to kick off the TSF announcement, mostly to introduce Duncan. However, someone managed to snap a picture of me that I think captured the feeling of awe that we've come so far in such a relatively short time.
I spoke to about 400 people at the conference, and I have a lot to follow up on. I also have a day job, 阿as those of you that I spoke to about Mantissa rather than Twisted know ;-).
If I talked to you about something at the conference, please don't hesitate to send me email reminding me about it. Ideally, send me email reminding me in one to three weeks. I have almost 1000 unread emails right now and while I try to be rigorous about using some unique features of Divmod's mail system to make sure I reply to each one, there is a certain volume of communication which no tool can help me cope with.
My first priority is blogging about interesting aspects of the conference in the next few days, before I've forgotten.
I'm a big fan of Nine Inch Nails. Not quite to the degree of buying
every Halo, but I have a number of his albums. So of course I've been
intrigued by his latest offering. Today, while looking at Nine Inch Nails "Ghosts I-IV'
website, I noticed an interesting bit of information:
The music and movie industries have been telling us for the last few years that digital restrictions are required in order to save their businesses from destruction. Well, Mr. Reznor has proven them wrong quite dramatically. Before I continue, let me address an obvious objection up front - I realize he's a superstar. However, the spokespeople for the RIAA that support their claims are also superstars: Lars Ulrich is hardly a starving artist laboring in obscurity. I'm not saying everyone can do what he did, only that the people who are already rich in the music industry can continue to be rich without the bullshit that they claim is critical.
The "Limited Edition", for those of you not up on the latest NIN happenings, is a three hundred dollar version of the album, containing a bunch of extras and a signature from Mr. Reznor himself. The full album, in lossless, non-restricted format, costs five dollars. There were 2500 copies of the limited edition.
Let me emphasize for those of you who might not be quite as up on the terminology that "lossless" formats (which NIN is selling for $5 here) are the highest quality format that it is possible to distribute over the internet. Other music producers, out of fear for eating their CD revenues, have mostly refused to provide digital copies of their music of this quality.
Also, to compare pricing: Apple typically charges 99¢ for a DRM-free song: it's not lossless, but it's 256kbps, which is fairly high quality. (I would not believe it if someone told me they could hear the difference, but there is a marginal difference in the perception of value here.) There are 36 songs on "Ghosts". $5 is roughly 14% of $35.64.
So now that I've established that NIN is selling higher quality goods, in a customer-friendly way, for a fraction of the price of the competition, let's do some math:
Coincidentally, it also proves that you don't need any RIAA thugs to help you do this, or "market" your work, assuming people already know who you are. You just need a web server, and a swimming pool big enough to put a million dollars.
We have SOLD OUT of the 2500 Limited Edition Packages.My great-uncle is fond of a saying. "It is better to be rich and healthy than to be poor and sick." Seeing this, I was reminded of it. It's not quite as catchy, but it's better to be customer-friendly and a huge success than reviled as corrupt and a failure.
The music and movie industries have been telling us for the last few years that digital restrictions are required in order to save their businesses from destruction. Well, Mr. Reznor has proven them wrong quite dramatically. Before I continue, let me address an obvious objection up front - I realize he's a superstar. However, the spokespeople for the RIAA that support their claims are also superstars: Lars Ulrich is hardly a starving artist laboring in obscurity. I'm not saying everyone can do what he did, only that the people who are already rich in the music industry can continue to be rich without the bullshit that they claim is critical.
The "Limited Edition", for those of you not up on the latest NIN happenings, is a three hundred dollar version of the album, containing a bunch of extras and a signature from Mr. Reznor himself. The full album, in lossless, non-restricted format, costs five dollars. There were 2500 copies of the limited edition.
Let me emphasize for those of you who might not be quite as up on the terminology that "lossless" formats (which NIN is selling for $5 here) are the highest quality format that it is possible to distribute over the internet. Other music producers, out of fear for eating their CD revenues, have mostly refused to provide digital copies of their music of this quality.
Also, to compare pricing: Apple typically charges 99¢ for a DRM-free song: it's not lossless, but it's 256kbps, which is fairly high quality. (I would not believe it if someone told me they could hear the difference, but there is a marginal difference in the perception of value here.) There are 36 songs on "Ghosts". $5 is roughly 14% of $35.64.
So now that I've established that NIN is selling higher quality goods, in a customer-friendly way, for a fraction of the price of the competition, let's do some math:
- march 6, today,
- minus the march 4th (the date that the "ghosts" website became fully
operational (according to wikipedia),
- is two days, times
- 2500 copies
- times 300 dollars
- equals SEVEN HUNDRED AND FIFTY THOUSAND DOLLARS IN TWO
DAYS.
Coincidentally, it also proves that you don't need any RIAA thugs to help you do this, or "market" your work, assuming people already know who you are. You just need a web server, and a swimming pool big enough to put a million dollars.