[development] Getting rid of core hacks for drupal upgrade tohappen. Need tips on the process.
yhager at yhager.com
Sun Apr 4 22:54:38 UTC 2010
> I'm answering on the dev. list because others might indeed be currently in
> the same predicament and we could probably all benefit from pooling our
> ideas on such problems, which are likely to become more frequent overall,
I am afraid that the nature of these hacks is different every time, which
makes each of us fight his own dragon. However, I might be wrong. feel free to
contact me off list to try and share insights and patches that might be
helpful to you guys.
> since D5 was the first version which saw significant for-hire developments,
> most of them likely to have much the same kind of issues.
Yes, that is probably very true. D5 was a Gold release at the time, and a lot
of folks who did not really understand opensource jumped on the wagon. D5
looked like it is enterprise ready, but it had a lot of problems with scaling,
which created the need for hacks. Some hacks were made to save time, some were
rightful patches that entered later versions of Drupal (user_load caching,
blocks caching, locking API...).
> And going out of
> support when D7 is released, real soon now :-)
Yes, that is a really good argument with clients. Wave the EOL at them and
they will do anything you say :)
More information about the development