Backward compatibility

I’ve been following the news about the further delays for Vista with some amusement, but have also gotten a lot of food for thought from some of the commentary.

Particularly, there are several articles discussing the problems Microsoft is having with Windows at this point because they have spent the last 10-15 years struggling with the issue of backwards compatibility. The result, the general consensus seems to be, is a horrible bloated mess of code that isn’t pleasing anybody. They mention OS X and how Apple has not hesitated to ruthlessly cut off older technology and are quite successful.

I notice in my case I use Firefox, and because the 1.5 and beyond are still rather buggy in the Mac version I’m still using the 1.0.7 version. There are a number of very nice new extensions that I would love to use, but cannot because they won’t work on my older version. But while I may grumble to myself about it, I don’t really hold it against Mozilla or the extension developers. And while there may be a handful of people unhappy about new systems not supporting their existing software (or hardware) I notice that Linux still seems to be able to move right along.

My point is that I don’t feel that we should be too much concerned about existing snippets and modules and plugins, if someone is totally dependent on one and for some reason cannot get it updated then they’ll just have to stay with their current version of MODx. I would hate to see MODx get trapped in the same snare that Microsoft is finding themselves, by trying to please everybody. If you remember the story about the farmer and his boy taking the donkey to market, you end up pleasing nobody.

I don’t know what everyone else’s thoughts have been on the subject; these are just what I’ve come up with.

Agree.

I’ve talked with Jason a while ago, and it seems to me that he will totally agree to this. Considering that we want to start a fresh system called Tattoo, so why don’t we start something new with MODx as well?

Absolutely agreed, and with the 1.0 core rewrite, we will experience the first of these growing pains. However, I have no intention of alienating existing users and developers and am working out several plans to support legacy tags and API support for existing components by using plugins; this will allow me to optimize the new core for the new tags and API and offload any performance loads or other inconveniences to the legacy support plugins. Certainly won’t support all existing snippets, as any components written directly against core tables using SQL (especially those that access content fields), will likely not be compatible (though with plugins and the new core, it may be more possible than I currently think). But with new tutorials, new forms of API documentation, and designer and developer migration guides, the pain should be very limited.

It’s better if we do it now, rather than regreting it later.
Snippets, plugins, and etc are just eye candy that can be re-coded by some other developers out there. If we get this core system nailed down on v1.0, then developers after developers will come contributing with recoded or created resources for MODx.

I agree with you all, backward compatibility should not prevent MODx to move forward with the new core. It has not in the past : you could have tried to keep every Etomite snippet backward compatible, but you didn’t go that way and developpers adapted Etomite’s best snippet to MODx.

Same will happen in the future, especially if (like I suspect) upgrading has such benefits that running older release won’t be an option for long...

Quote from: OpenGeek at Mar 29, 2006, 09:17 PM

But with new tutorials, new forms of API documentation, and designer and developer migration guides, the pain should be very limited.

Documentation will be key, most definitely... I don’t know what is planned there but the testing period for the new core/rev should allow the testing team to write the doc in time for the release.

Quote from: davidm at Mar 30, 2006, 03:25 AM

Quote from: OpenGeek at Mar 29, 2006, 09:17 PM

But with new tutorials, new forms of API documentation, and designer and developer migration guides, the pain should be very limited.

Documentation will be key, most definitely... I don’t know what is planned there but the testing period for the new core/rev should allow the testing team to write the doc in time for the release.

Absolutely, I hope to put plans in motion for testing, additional coding tasks, and documentation tasks, as soon as I have the prototype functioning. More very soon...