[IzzyMurad]

That's exactly why I went with Django/Python instead of RoR/Ruby.

I have no problem with keeping software up-to-date but I don't want to make that a main task because some "cool" kids easily get bored and keep phasing out stuff which break production apps and/or causes security issues.

[fbuilesv]

If you "have no problem with keeping software up-to-date" then don't complain about these type of changes. As developers we either are responsible about version policies or we're not. Let's take Ruby 1.8.7 as an example:

If you were responsible you went through several patchlevels of Ruby 1.8.7, you're using the latest release (to fix security issues if nothing else) and you had five years to migrate to 1.9 (which most likely meant changing nothing in your code, just testing it).

If you were not responsible and you're running on something different to the latest patchlevel version then you're already running on faulty/unsecure software. Killing support upstream (again, after five years!) is not likely to change whatever you were [not] doing.

PS: Please don't refer to people like the ruby-core team as "cool kids who easily get bored". We all have our biases but name-calling doesn't add anything useful to discussions.

[blablabla123]

> and you had five years to migrate to 1.9

Given that you were at the project right from the start and allowed to spend time necessary. It's funny to hear people moan on the one hand about corporate that use Java EE or even Cobol but on the other hand refuse to accept that in order for their software to be usable, it needs to be stable in some senses.

[fbuilesv]

When you joined a project is irrelevant. If you were hired two days ago and only found out about this now: tough luck, you have some work to do [0]. Even "stable", older platforms like Cobol have to deal with this (Micro Focus makes money off it with products like their Cobol set of tools (http://www.microfocus.com/mcro/cobol/index.aspx) [1]).

[0] Or maybe not. Your non-core [2] apps that run on 1.8.7 will still work tomorrow. Most of these applications are internal too so the risk is even less.

[1] There's almost always a 3rd party vendor who'll take advantage of a situations like this. They will make it your life easier and they'll charge you accordingly. See http://railslts.com/ for another example.

[2] If the applications that are putting the food on your table are running in an environment where no one thinks about this kind of stuff, then maybe it's time to take the wheel and start educating your team on why this is important.

[blablabla123]

[0] Precisely.

[1], [2] After all management does such decisions. I have warned people face-to-face, via E-Mail, through all possible channels. So if things go wild, it's their problem, not mine.

[VeejayRampay]

You went with Django/Python eh?

Which Python exactly? 2.6? 2.7? 3.3? That a Python user of all people would whine about lack of stability and consistency is extremely funny.

[IzzyMurad]

Django 1.5 (latest stable version) requires Python 2.6.5 or above, so it doesn't matter.

[bdcravens]

Doesn't Django/Python have its own version headaches? (Python 3 came out 5 years ago, but Django didn't officially support until February of this year)

Phasing out old version of the underlying language isn't uncommon. For example, Oracle doesn't even support Java 6 anymore, which was released in 2007.

[JshWright]

I think the difference is that Python had a much more realistic plan for the backwards incompatible changes. The fact that the transition will likely take the better part of a decade is a _feature_, not an issue (and there will be supported versions of 2.x throughout that time).

[revskill]

I always have respect for people using Python to make a living. But it seems that you don't use the language as your main tool (maybe as a toy). Please, do respect all other's work even if you don't use (or hate) it.

[jammi]

Yeah, there's nothing like the Python 2 to Python 3 transition going on there for the umteenth year.

[JshWright]

The difference is, the Python developers had a realistic view of what this transition would look like, and it's very intentional that it will have taken the better part of a decade by the time all is said and done.