Please, keep changing!

What articles are those?

untitled-[2].html (3.67 KB)

The most recent and famous ones are:

http://gilesbowkett.blogspot.com/2012/02/rails-went-off-rails-why-im-rebuilding.html

http://merbist.com/2012/02/29/learning-from-rails-failures/

I do respect their opinion. I just think I should state my opinion

too so that their opinion don’t become the only one.

Just to say that we shouldn't care when people try to offend, BUT even
if someone is doing that we should definitely listen to critics, try
to improve what is wrong and not being :emo: about that.

Anyway I didn't find any of the posts as personal attacks or bad
suited but perhaps is just me.

Cheers.

From both articles, I've understood that they would prefer Rails to be more backward compatible in new releases.

I know you want to listen to their critics and that is exactly the reason that I felt I should state that I prefer the API to be changed to better in major releases instead of worrying too much about backward compatibility.

Also I do find valuable a small and readable code-base, so keeping lots of code just to be backward-compatible doesn't feel right to me.

Perhaps you got a wrong impression from my original message intention.

I'm not criticizing them for expressing their opinions. I was just wanting to tell you that there are other opinions about this too to take into consideration and I'd like you to listen to our opinion too.

Cheers,
Rodrigo.

hi,

until now, I was only a reader,
but this thread bother's me.

From both articles, I've understood that they would prefer Rails to be
more backward compatible in new releases.

I would prefer it. It's not only a rails issue, also a plugin / gem
issue.
Some time's you got a gem and your app depend's on it, but it wan't
work with a new rails version. What should I do, in such cases?
What will it cost to redesign?

I know you want to listen to their critics and that is exactly the
reason that I felt I should state that I prefer the API to be changed to
better in major releases instead of worrying too much about backward
compatibility.

Also I do find valuable a small and readable code-base, so keeping lots
of code just to be backward-compatible doesn't feel right to me.

When I read this I got following question's:

What's the life time of a rails app?

Who should use Rails?

What will it cost in real money, to upgrade a bigger Rails App?

How long will there be security-fixes for older Rails Versions?

How long will my used plugins be useable?

In my opinion, it's hard to explain a manager, Yeah, we have to make a
little upgrade from Rails X.Y.Z to X.Y.ZZ, but it will last 2 weeks,
or more because of API changes and we need to fix some
incompatibilities. Such minor releases have to be drop-in
replacements.

regards
dieter

Keeping backwards compatibility and moving forward are contrary goals
pulling from each other. Rails tries to keep a balance while leaning
on the side of moving forward.

Some people like that, some people don't. There's no solution to that conflict.

Rodrigo I personally appreciate a lot your email. Sincere positive
feedback is absolutely great, I bill *less* hours everyday to work on
Rails, I pay the docs server from my wallet, I do it because I like
it, nobody owns me anything and it is my pleasure, but it is good to
hear some positive words.

Thanks,

Xavier

PS: And of course sincere negative but constructive feedback is also great.

I do respect their opinion. I just think I should state
my opinion too so that their opinion don't become the
only one.

I doubt that will ever be the case. There seems to be some
number of people that believe that Rails works well enough
for their needs. Beside, here you are only preaching to the
choir. Although, I agree that the core team has certainly
earned our thanks and deserves to hear it.

hi,

until now, I was only a reader,
but this thread bother's me.

From both articles, I've understood that they would
prefer Rails to be more backward compatible in new
releases.

I would prefer it. It's not only a rails issue, also a
plugin / gem issue.
Some time's you got a gem and your app depend's on it,
but it wan't work with a new rails version. What should
I do, in such cases? What will it cost to redesign?

I know you want to listen to their critics and that is
exactly the reason that I felt I should state that I
prefer the API to be changed to better in major
releases instead of worrying too much about backward
compatibility.

Also I do find valuable a small and readable code-base,
so keeping lots of code just to be backward-compatible
doesn't feel right to me.

When I read this I got following question's:

What's the life time of a rails app?

Who should use Rails?

What will it cost in real money, to upgrade a bigger Rails
App?

How long will there be security-fixes for older Rails
Versions?

How long will my used plugins be useable?

In my opinion, it's hard to explain a manager, Yeah, we
have to make a little upgrade from Rails X.Y.Z to X.Y.ZZ,
but it will last 2 weeks, or more because of API changes
and we need to fix some incompatibilities. Such minor
releases have to be drop-in replacements.

Personally, I did not find going from 2.3 to 3.0 so hard as
to warrant much comment, having previously switched to
Bundler in RoR-2.3 using Yehuda's preinitializer hack.
And I found the upgrade helper in 3.0 of inestimable
value. But it was time consuming and I must confess to a
little weariness when some of changes required treading
through the source code altering syntax in ways that
appeared to me more form than substance.

Moving us to 3.1 from 3.0 is only hung up at the moment
because of the issue I have encountered with the
sqlite3-ruby gem and AR-3.1. That will eventually be
solved
but it has already taken an inordinate amount of time to
resolve and no doubt a considerable amount more will be
required. The one thing I do glean from this is that I
believe the RoR core team does not consider the desirability
of being able to stay current on long term Linux releases as
seriously as others who spend money happen to.

The "enterprise" is where the money is and "enterprisey"
people tend to value stability over new features. I would
rather write code for Rails-3.1/3.2 and 4.x when the time
comes, but I have to keep existing applications working
first. Every hour worked on an existing application
simply to accommodate an incompatible change introduced by
a point version update to Rails or some other gem it
depends upon is an hour lost from other, more profitable,
activity.

We run systems with OS's CentOS-4, 5 and 6. The 4's are at
their end of life, today in fact, and the services that they
hosted are almost all moved to 6 based vm systems. But the
5's have an eol five years from now and the cost of moving
things off them has to be justified. I can arrange for that
to happen using sleight of hand vis a vis switching to
virtual machines, but that will take time as well.

Deciding to deprecate things provided by mainline core
distributions in favour of replacements that may not be
supported on, or even available for, a current long term
support release I believe is of questionable benefit to
Rails in the long term. In our case I was able to use rvm
to deal with the requirement for ruby-1.8.7 (CentOS-5 ships
only 1.8.6 and we did not run any RoR apps on the 4s) but
sqlite is proving to be somewhat more intractable. And
given its peripheral use in our application, caused by yet
another gem dependency no less, that is almost maddening.

Sexy is over once you are married to an app. If you make
it hard for organizations to keep the application
framework up-to-date without rebuilding their entire
platform then they will eventually move to something that
makes it less hard. Ultimately it becomes simply a
question of where money is spent and who gets to make the
decision.

RoR is doing, but at the same time I believe that it
warrants consideration when making changes. A little PR on
the matter might go a long way in RoRs's favour as well.

I didn’t find any of the posts as personal attacks or bad
suited but perhaps is just me.
Even though I’m not as involved in contributing to Rails as 1.5 years back but I found them very offensive. A lot of people, including you, put a lot of hard work into Rails. And I thought they were inconsiderate and demanding in their ways.

But I’m glad to know that it didn’t bother you Santiago! Keep up the awesome work with Rails. :slight_smile:

Cheers,
Rohit Arondekar

http://rohitarondekar.com

Hi Consul, I didn’t answer this message before because I decided to
write an article first sharing my experiences with programming tasks
this week:

http://rosenfeld.herokuapp.com/en/articles/ruby-rails/2012-03-04-should-we-move-forward-or-remain-backward-compatible

So, now I'm able to answer you. Please, see comments inline below.

hi,
until now, I was only a reader,
but this thread bother's me.
From both articles, I've understood that they would prefer Rails to be
more backward compatible in new releases.
I would prefer it. It's not only a rails issue, also a plugin / gem
issue.
Everyone agrees on this and that is exactly why Rails 3 was targeted

at plugin authors. Rails had to attack several other needs before
and couldn’t take care about its API for gem developers before. So,
in Rails 3, a special attention was given to plugin authors and it
should be easier for future upgrades to be done with regards to gem
compatibility issues.

Some time's you got a gem and your app depend's on it, but it wan't
work with a new rails version. What should I do, in such cases?
I think it is always important to have a glance at plugin sources

before you decide to use them. You’ll be able to understand if
monkey-patches were required and how this plugin will impact on
future upgrades and this will save you lots of work. You’ll also be
able to see how good its test coverage is in case you’ll have to
take over its maintenance.

What will it cost to redesign?
What is the cost of keeping a bad API the next time you'll have to

use it?

In the article above, I showed how a good API may allow me to

complete my work in a few hours while a bad API will get me done
after a full week.


I know you want to listen to their critics and that is exactly the
reason that I felt I should state that I prefer the API to be changed to
better in major releases instead of worrying too much about backward
compatibility.
Also I do find valuable a small and readable code-base, so keeping lots
of code just to be backward-compatible doesn't feel right to me.

When I read this I got following question's:
What's the life time of a rails app?
All applications I've worked on in the past decade had a life-time

of “forever”.

Who should use Rails?
Please, read the article above.
What will it cost in real money, to upgrade a bigger Rails App?
How much does it cost in real money for writing software using bad

APIs?

How long will there be security-fixes for older Rails Versions?
It is not feasible to keep investing effort on supporting old Rails

versions and that is the reason I think we should be always trying
to be up-to-date with our frameworks as a top-priority.

When you delay the update it can become really hard to do it and big

softwares like Gitorious, Redmine and ChiliProject couldn’t upgrade
from Rails 2 yet.

How long will my used plugins be useable?
It will depend on how important you consider taking a look at its

source code and community before deciding for it.

In my opinion, it's hard to explain a manager, Yeah, we have to make a
little upgrade from Rails X.Y.Z to X.Y.ZZ, but it will last 2 weeks,
That is not true. Minor versions don't make incompatible changes to

API.

or more because of API changes and we need to fix some
incompatibilities. Such minor releases have to be drop-in
replacements.
They are. But managers must understand that you have two options

when deciding for some framework. You can get a stable framework
that won’t change its API but they must know that features will take
longer to get done too with such frameworks. If they decide to adopt
one that can respond faster to requirement changes or new feature
requests, they must accept that some time will have to be dedicated
for doing major upgrades to their application to a newer version
from time to time and that this upgrade will require some time and
effort too.

Xavier, I'd like to thank you very much for all the work you've been putting on Rails documentation infra-structure for the last years.

I do appreciate it a lot as I find the documentation to be *the most important* feature of any framework or library, tied with automated tests and API design.

When I complained about lack of documentation in Rails 3, I wasn't blaming you in any way.

I always thought that the main issue is that Rails core developers don't take documentation as serious as they take automated tests. The culture is:

"We have already opened docrails write access to anyone, so if you find something missing in the documentation, fix it yourself and let us work on new features and refactorings."

The problem is that usually the best person to document a new feature is the one who developed it. But as long as he wrote a test for it, it is fine. Finished. No need for including the documentation changes in the same commit.

I'm not saying that this happens with every one, but it happens a lot and it is the reason we have lots of gaps in the API documentation and sometimes the guides are not updated to reflect some changes.

In my opinion, developers should worry about documentation as much as they're worried about their test suite and they shouldn't accept patches lacking documentation updates.

But I've already expressed those opinions in the past and I don't think it changed anything, so I guess we'll continue to have some delay in the documentation update process.

But that is not your fault. Thank you very much for all your effort and money put on Rails documentation. They're much appreciated.

Cheers,
Rodrigo.

For the past few weeks I've been working on Rails app that has grown
over about 3 years to around 25kloc. The app was stuck at Rails 2.1.2,
uses quite a few gems/plugins and had a fair number of monkey patches to
Rails itself and the plugins.

It took me 20 to 30 days to convert this app to Rails 3.2.2; the exact
amount of days is hard to pinpoint as I did a lot of other cleanup and
things that weren't strictly necessary, such as rewrite queries in the
new style. Simply put, the effort I spent on this task is utterly
negligible compared to the programming effort in the life of that
application so far. Even more so when the whole project is considered.
What made this update possible at all was the solid test coverage.

Interestingly, changes in Rails itself were the least of my problems.
The code was and still is in bad shape. Apparently that's what you get
when an app grows over several years with changing programmers and no-
one to enforce a deliberate architecture and good style.

Don't allow your code to degenerate into a mess. Know, assess, and apply
the advice in the available books on Ruby and Rails good practices. If
an upgrade to a newer Rails version seems daunting, it may well be
because it exposes problems with your codebase that are quite
independent of Rails itself.

Michael

On Domingo 04 Marzo 2012 20:36:12 Michael Schuerig escribió:

I kind of understand this feeling. I don't write tests for my views, for example. So, you'd have to manually check all your views to see if some Rails changes in the view layer broke your application...

I'm curious... How many of you are really testing the output of your views? I'm not talking about integration tests where you use only a few parts of the view to test some specific behavior.

Cheers,
Rodrigo.