Comments for Dries:
From day one, I decided not to care about backward compatibility and it has been one of our core values ever since. (However, we only break your code, not your data.) Either you like that, or you don't.
Straight from the horse's mouth. :) Thanks. For Derek: First off, excellent and very helpful input.
However, that's not an ideal model, since it makes the cost of using drupal pretty high. ... most people trying to use drupal to setup a website aren't going to have those skills and that experience to draw from (nor many thousands of dollars to hire someone who does). If one of the motivating philosophies behind drupal is "down with The Man, let's help the underdog" (which I totally support), that doesn't quite jive with "only if the underdog is already a computer programmer, or has a $20K budget for their website".
This hits the nail directly on the head. A small addition, perhaps providing the means, rather than enforcing the will is a good approach. I dream of Drupal switching from cvs to svn. Better access methods (https), finer grain access control, access control lists, etc. We can have a guideline for a contrib module's svn directory structure like: /my_contrib head tags 4.5 4.6.4 4.6.5 4.7-BETA4 ... Contributors can choose if they want to use it or not. It's very little work for a contributor to checkout the 4.6.5 version of their module, fix some bugs, and commit the changes just for that version of drupal. Much easier with SVN than CVS (I think). Another plus is that people who depend on their code can just export the correct tag. A lot easier too... ie: svn co https://svn.drupal.org/respositories/contributions/my_module/tags/4.6.5 Ben