[felipemnoa]

Considering the amount of none trivial work about having to port your apps from one Rails version to the next I would be surprised if the Director didn't get part or most of the blame for forcing them to use Rails. And saying that they could just stay in an old version is not valid. When bugs are discovered in the old version most likely they will not be fixed because everybody has already moved on. Enterprise projects already have a high rate of failure and building it on a platform that has a history of making substantial changes on every new version is a really, really bad idea.

An honest risk analysis of the enterprise project would raise a huge red flag for using a technology that continues to change substantially in every version such that it is not backwards compatible.

[skidooer]

> When bugs are discovered in the old version most likely they will not be fixed because everybody has already moved on.

Is this a real problem? If you encounter a bug in an older version of Rails, why not just fix it and carry on as usual? Fixing bugs is part of the job of being a developer. If you are afraid to fix bugs, your application isn't going to last long no matter what language, framework, or platform you choose.

[felipemnoa]

I'm talking about bugs in the Rails framework. I think very few people would like to be having to maintain an outdated framework. And for the ones that actually do decide to maintain a framework that they did not develop themselves it will cost them a lot of money.

[Aqua_Geek]

> I'm talking about bugs in the Rails framework.

I think skidooer was as well.

> I think very few people would like to be having to maintain an outdated framework. And for the ones that actually do decide to maintain a framework that they did not develop themselves [...]

How is maintaining an open-source framework that somebody else made different from maintaining a framework built in-house? At the end of the day, bugs will still be found and need to be fixed. Yes, your devs might be more familiar with your framework than with a third-party one, but I think that is only the case if you can keep your team small and prevent churn and specialization. Regardless of which direction you go, devs need to understand what is happening inside the framework - it can't be a magical black box.

> [...] it will cost them a lot of money.

More than writing something from scratch?

[felipemnoa]

Well, I guess we just have to agree to disagree. When choosing a framework one of my criteria is that somebody else is doing all the work to maintain it so that I can benefit from their work. If I have to maintain it then what is the point? I'm trying to save time here, not add more time to my schedule.

[skidooer]

You certainly make a valid point, but I must add:

Rails is a fast moving target because they are always looking for new ways to save you time. As I mentioned in a previous post, the Rails 1.0 API is painful compared to the current generation. You are saving massive amounts of time during development because the project has evolved so far.

Spending a few minutes patching a framework bug once every five years pales in comparison to the gains you are seeing in development time.

To each their own, but I'd rather have a framework that is better than have a framework that knows it could be better, but won't make the changes because it might break some several year old app.

[skidooer]

I too was talking about the Rails framework. It's actually a really nice read. I've fixed a couple of bugs in it myself.

The thing to remember is that each major release of Rails is fairly well tested. The number of actual bugs you are going to encounter are low. The investment in fixing them is therefore going to be low, should you actually encounter any to begin with.

The Rails codebase is simply an extension of your own codebase. While it is not fun to fix bugs in any capacity, there is no reason to fear fixing bugs in third party code. It is no worse than fixing your own, which also costs a lot of money.

I've been using Rails since around the 0.8 release timeframe. I have seen many major changes along the way. They have all been positive improvements to my workflow and the theoretical issues you describe have never been real issues. I still have one app chugging away on Rails 1.1 and it works just fine. The only problem it has is that it is not nearly as fun to maintain because it doesn't have all the newer major improvements. It would be a sad day if we had to go back to, or were still using, the 1.0 API. The Rails people are doing the right thing.

[varikin]

And it was non-trivial to go from Java 1.4 to 1.5.

[felipemnoa]

With all due respect, I don't know what you are talking about. Programs in 1.4 run fine in 1.5. Every time there is a new version of Java I install it in my machine and just continue working as usual. I would be really upset if I had to spend time trying to make everything work again with every new version. They deprecate methods and functionality but they do not remove it. Java is not that much older than Ruby/Rails and it is pretty stable. Ruby/Rails may be great but I really don't want to go through the pain of having to port my code to the next version. I rather spend my time on adding new features.

Even Android, which is many times younger, never does this. Everything is always backwards compatible. Android developers would be up in arms if they just decided to break all apps in a new version of Android. Granted, it could still happen because nobody is perfect. Although it has never happened in any of my apps and I don't know if it has ever happened at all except for the early Beta period. When something is no longer supported they deprecate the functionality but do not remove it.

[varikin]

1.5 did introduce at least one major backwards incompatible change. A new keyword which meant any variables named enum now broke the app.

Installing a new Java version on your desktop to run some app is different than rolling out a new major version of JVM/language for an enterprise application. There is a lot that went into ensuring everything still worked, including all dependencies, and that performance was acceptable. Maybe heap options needed to be changed because of how GC changed.

[felipemnoa]

OK, I stand corrected. Still, that is almost insignificant. But yes, nobody is perfect.

[speleding]

> Java is not that much older than Ruby/Rails

According to wikipedia: Java = 1995, Ruby on Rails = 2004