In both worlds high-stakes businesses are going to stick to the "stable" release while personal projects explore the new waters. Django's failure to make the shift has resulted in all those personal projects not making the shift.
Django, from my point of view, seems to be approaching this from the wrong direction. They are waiting for the community to shift to Python 3, but at the same time the community is waiting for Django to shift.
Er, no, we're not "waiting for the community to shift".
When Django 1.0 was released, we supported minimum Python 2.3. Dropping 2.3 and then 2.4 were major logistical hurdles; they were incredibly widely deployed, and were the stock Python for many platforms with long-term support. So it was going to take a while, no matter what, for us to sensibly deprecate those Python versions without just throwing a bunch of our users under a bus. And, of course, deprecating everything older than 2.6 is a prerequisite for starting to actually adopt 3.x.
Meanwhile, the first few releases in the Python 3 series weren't really meant for widespread adoption, ever. They were there so people could start getting a taste of Python 3 and working out a migration process while shaking out remaining issues for Python itself.
We are now at a confluence of two very happy things:
1. We've dropped our support for the older Python 2.x releases, without just screwing over a bunch of people, and by year's end we'll be a minimum-2.6 project, and
2. Python 3.2 (the current 3.x) is really quite a nice release, and Python 3.3 (later this year) looks like it'll really put the spit and polish on the Python 3.x series, meaning it's a very attractive time to be targeting Python 3.
This is the first time we've realistically been in a position to actually make the jump, and we're taking that opportunity.
Fair enough, the impression I got from the above link was that Django was waiting for the community.
I'll hold back on commenting now because my insight into the Python community is limited to what I hear from friends who develop on Python. Though something I've noticed is that many of them are making the switch to Node.
And, to be fair, as soon as the py3k WSGI spec was agreed upon the Django core developers also started implementing and pushing this transition strategy. It was a big deal at DjangoCon '11.
I think a lot of people who are really interested in shifting to Python 3 for those experimental projects are just using different web frameworks.
The real problem is that Django isn't the only problem. I've started cataloging the packages that are supporting Python 3 in my project, and there are still several that are critical to it that haven't made the transition. My web framework is the least of my concerns in that regard (considering it already supports Python 3).
I think its important for frameworks like Rails / Django to always support the latest and greatest and at the same time give people time to upgrade for example how the rails team have done it now which is in rails 4 move to 1.9.x exclusively but in rails 3.2 still support ruby 1.8.7
developers have choice. when they're starting new app / new project they can opt for the older version or if they're feeling lucky adopt the new stack.
the important thing is developers should have a choice, because i firmly believe more choice leads to more innovation.
its not like when rails 4.0 come out they're going to force everyone to upgrade, you can upgrade at your own pace.
I think this is a bit disingenuous. Ruby 1.9.0 was released Christmas 2007, 1.9.1 was released in January 2009, and 1.9.2 was released August 2010. Ruby 1.9.2 was the first release that most Rubyists considered "stable".
For the uninitiated, Ruby's tiny version is the equivalent of Python's minor version (Ruby 1.9.2=>1.9.3 ~ Python 3.2=>3.3).
Rails 2.3 supported almost the entire Ruby 1.8 series (except for one release, 1.8.3 I think, that had a serious bug). Rails 2.3 had experimental support for Ruby 1.9.1 when it shipped, but most people used Ruby 1.8.6 or 1.8.7, as Ruby 1.9 was still somewhat unstable at that point.
Rails 3.0 (which also shipped in August 2010) dropped support for Ruby 1.8 versions before Ruby 1.8.7, and shipped with stable support for Ruby 1.9.2. Ruby 1.8.7 shipped in May 2008, and was very compatible with Ruby 1.8.6. We (the Rails team) continued full support for Rails 2.3, which supported Ruby 1.8.6, until August 2011, when Rails 3.1 was released.
We have announced that Rails 4.0, which we still have not shipped, will drop support for Ruby 1.8.7. This means that we have dropped support for one version of Ruby (we will still support 1.9.2) in more than 2 years. That hardly qualifies as "New Ruby alpha? Deprecate everything!"
Short timeline:
- August 2006: Ruby 1.8.5
- March 2007: Ruby 1.8.6
- December 2007: Ruby 1.9.0 / Rails 2.0
- May 2008: Ruby 1.8.7
- June 2008: Rails 2.1
- November 2008: Rails 2.2
- January 2009: Ruby 1.9.1
- March 2009: Rails 2.3
- August 2010: Ruby 1.9.2 / Rails 3.0
- August 2011: Rails 3.1
- October 2011: Ruby 1.9.3
- January 2012: Rails 3.2
Releases of Rails 2.x all supported Ruby 1.8.2 and above. Releases of Rails 3 have supported Ruby 1.8.7 and Ruby 1.9.2 and above. The only change in Ruby support since Rails 2.0 was requiring at least Ruby 1.8.7 in Rails 3.0. There is an announced change for Rails 4.0, but Rails 4 has not been released yet, even in betas.
Rails is moving more quickly at adopting Ruby 1.9 than Django is at adopting Python 3, but that is because it was possible, from the get-go to support both Ruby 1.8 and Ruby 1.9 in a single codebase. That was not possible with the move from Python 2 to Python 3.
The typical argument I've heard about the difference is that Ruby 1.8 to 1.9 was a relatively smaller release. I think this underestimates the work that the Ruby team put into compatibility while developing Ruby 1.9, especially given the large encoding-related change made to Strings in Ruby 1.9 (Ruby 1.9 Strings are encoding aware, while Ruby 1.8 Strings are semantically simple byte Arrays).
Either it's a bug or I missed something. It could be that there were fundamental bugs in Ruby 1.9.2.
Again, Rails 4.0 is not out yet, even in betas. We're currently in the planning stages, with a lot of movement on master, so master is in a state of flux at the moment that doesn't really reflect what a release will look like.
Having investigated this a bit, it seems like there are a number of bugs in Ruby 1.9.2 (including some crashers) that make us want to steer people to 1.9.3.
All Rails core team members have running apps on the latest version of Rails, and Ruby 1.9.3 was the first version that everyone felt comfortable shipping to production with. So Rails 4 removes support for Ruby 1.8.7, and requires the first "stable" version of Ruby 1.9, based on our experience bringing apps to production.
One of the things I love about Rails is because it IS quick to adopt the latest (stable) Ruby, and doesn't hang around too long supporting old versions which really, not too many of us are (or should be?) using anyway. I have found the Ruby community are generally eager to use the most up to date Rubies ...some are even on Ruby 3.0 ;-)
I hate titles "Framework A is doing this, why framework B isn't doing this?"
Use what seems best to You. Rails always tend to have faster movement with Ruby support, but to be honest having at least 1 year is enough to redeploy app with new Rails & Ruby. If not then you're doing it wrong.
Rails team: "New Ruby alpha? Deprecate everything!"