5 ms·

Django team: "We're planning to shift to the 4 year old Python 3 over the next 2 years" Rails team: "New Ruby alpha? Deprecate everything!"

spitfire 15y ago
Now which would you bet your business on? It'd be nice if things could move a little faster. But the alternative is wild-wild-west.
- taybenlor 15y ago
  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.
  - SoftwareMaven 15y ago
    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).
  - ubernostrum 15y ago
    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.
    - taybenlor 15y ago
      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.
      - tbatterii 15y ago
        there wasn't even an agreed upon spec for WSGI on python 3 until last year IIRC. That needed to happen first.
        maaku 15y ago
        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.
        tbatterii 15y ago
        I think every framework did. cherrypy landed there first.
- hippich 15y ago
  It depends on your business, right?
- jemeshsu 15y ago
  >Now which would you bet your business on? Scala/Play! I was fed up of waiting.
superxor 15y ago
> we hope to be targeting up to Python 3.3 All major projects seem to be adding support up to the latest Python 3 version, not the 4 year old 3.0 one.
wycats 15y ago
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).
- bcardarella 15y ago
  > we will still support 1.9.2 [in Rails 4.0] How can the Core team claim to support 1.9.2 in Rails 4.0 when the minimum version of Ruby required to run the test suite is 1.9.3?
wakeless 15y ago
What I like about this comment, is that it has pissed off both sides of the story.
artellectual 15y ago
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.
burnhype 15y ago
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.
AstonJ 15y ago
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 ;-)

spitfire 15y ago

Now which would you bet your business on? It'd be nice if things could move a little faster. But the alternative is wild-wild-west.

taybenlor 15y ago
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.
- SoftwareMaven 15y ago
  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).
- ubernostrum 15y ago
  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.
  - taybenlor 15y ago
    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.
    - tbatterii 15y ago
      there wasn't even an agreed upon spec for WSGI on python 3 until last year IIRC. That needed to happen first.
      - maaku 15y ago
        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.
        tbatterii 15y ago
        I think every framework did. cherrypy landed there first.
hippich 15y ago
It depends on your business, right?
jemeshsu 15y ago
>Now which would you bet your business on? Scala/Play! I was fed up of waiting.

superxor 15y ago

> we hope to be targeting up to Python 3.3 All major projects seem to be adding support up to the latest Python 3 version, not the 4 year old 3.0 one.

wycats 15y ago

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).

bcardarella 15y ago
> we will still support 1.9.2 [in Rails 4.0] How can the Core team claim to support 1.9.2 in Rails 4.0 when the minimum version of Ruby required to run the test suite is 1.9.3?

wakeless 15y ago

What I like about this comment, is that it has pissed off both sides of the story.

artellectual 15y ago

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.

burnhype 15y ago

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.

AstonJ 15y ago

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 ;-)