Future-Proofing: Upgrade Paths and Backwards Compatibility

The users previous thread: http://drupal.org/node/228670#comment-753957

The difference between users hacking core and Drupal dev's moving core forward is simple:

Major versions take on API changes and an upgrade path is created.

minor versions do not offer new features and as such the APIs don't change, because only security holes are patched and bug fixes added.

Thus a user who hacks version 5.2 will overwrite all changes when a security release of 5.3 is out. This is why hacking core is a bad idea. Besides, hacking core is unnecessary with the way drupal is wriitten, you can use hooks and create your own modules to plug into core where you want.

Modules for verison 5.x would always work for 5.x. Modules need not be updated until the next major release except under very rare occasions.

This node: http://drupal.org/node/65922 that I've given you before answers most of your questions with regards to upgrade paths, time between releases and the like. Your comments from that handbook page have been removed as they added nothing to fold into the handbook page and were only biasely based on your own opinions and epectations about how Drupal should work for you.

_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )

Note: My comment here is the same as tbcreeks other 2 threads. I don’t like spamming my views into multiple threads, but since the original question has ended up in 3 threads I don’t seem to have an alternative.

The concerns of tbcreek are concerns of mine and probably should be concerns of any potential Drupal user. There is an appearance with Drupal development in regards to backward incompatibility issues that it is badly managed or not managed at all.

There doesn’t appear to be an appropriate evaluation of the worth of changes versus the pain they cause. There doesn’t appear to be appropriate comparison and evaluation of alternative methods that don’t force backward incompatibility.

There is an appearance that the designers consider backward incompatibility of zero consequence. The appearance is that there is a couldn’t care less attitude towards creating backward incompatibility. The appearance that backward incompatibility is done for the most trivial reasons and in many cases of such debatable worth that other people may actual consider the original to be better.

Things like changing the name of interface parameters because someone thinks (and arguably at that) that another name is better, and then using the original name for something else. Doing that to interface parameters when those changes create backward incompatibility to possibly many users is just crazy. It is far too trivial for the pain.

This appearance is giving Drupal a bad name. It reduces the number of people that use Drupal and a consequence of the lower user base is that Drupal will not advance as much as would with a bigger user base.

Having appropriate management of these issues, both in reality and in a way that is obvious to users, will actually help Drupal be the leading CMS, not hinder it. It needs to be seen to be being done as well as being done.

Some suggestions to help are as follows:

1) Some major revisions, at least each alternate major revision, should be specified as a revision that is 100 per cent backward compatible. Note: It is a lot easier to make 2 changes at once than it is to make 1 change at one time and then within a short period later to have to make another.

2) I presume that there are already special rules relating to development for any development that will result in backward incompatibility. Special rules such as that each such change requires a written justification and evaluation etc along with a comment period, polls etc. If not, there needs to be. Further, this control/management of backward incompatibility needs to be seen to be being done. I would suggest that the current area in the forum on drupal.org for discussion of Development (working groups) split the Drupal.core section into two parts. One part for discussion of proposed changes that could create backward incompatibility and one for the remainder of Drupal.core development.

Please note: I am not suggesting that there is to be no backward incompatibility. Sometimes this is needed. Sometimes you need to throw out old interfaces in order to stay bleeding edge. I am simply stating that this special area needs a proper evaluation methodology and proper management and users and potential users need to be able to see that this is occurring.

The other extreme is AutoCAD. If they put in something wrong in 1982, they've left it alone in order to be backwards compatible. Exceptions are few. Instead of fixing problems, they've been rewriting the documentation and calling them features.

So it's refreshing to see the opposite approach. My personal opinion is to go ahead and innovate, but not disturb things unnecessarily. One could point at the histories of the Volkswagen and the ISA computer for examples of reasonable pursuit of innovation.

However, it would be nice to have a bridge layer that could run old modules. With a performance hit, most likely. So D5 modules would run on this module which runs on D6. If you needed to run a D4 module, then just string together the two bridge modules.

I don't know what the technical challenges to this would be, and assume that they would be formidable, but this would greatly speed up adoption of newer versions, and I think it would be worth it. The performance penalty would encourage porting of existing modules.

Just imagine if Microsoft threw away all their accumulated garbage & wrote an efficient OS, and then added a layer that allowed old stuff to run, but at a cost.

Just one person's fantasy.