Converting Add-ons

I’m wondering which is the preferred method of convering and add-on for use with Revolution.

1. Creating a Revolution specific version.

2. Creating a version that will run in 0.9.6 AND Revolution (where practicable).

Both have advantages and disadvantages. The biggest plus for #1 is that upgrades and bug-fixes to an add-on will be available to both user groups.

Also, with respect to #1, is there (or could/should there be) an easy call to determine if an add-on is running in Revolution (e.g. $modx->isRevolution)?

Quote from: BobRay at Jul 23, 2008, 02:11 AM

I’m wondering which is the preferred method of convering and add-on for use with Revolution.

1. Creating a Revolution specific version.

2. Creating a version that will run in 0.9.6 AND Revolution (where practicable).

Both have advantages and disadvantages. The biggest plus for #1 is that upgrades and bug-fixes to an add-on will be available to both user groups.

Also, with respect to #1, is there (or could/should there be) an easy call to determine if an add-on is running in Revolution (e.g. $modx->isRevolution)?

My instinct is that it will be better to create a Revolution specific version. Only the simplest of add-ons will make sense to author the same way for the new and legacy core, and by trying to make the more elaborate ones work in both, you will add further code complexity and quantity that will decrease it’s efficiency in both places. And since in 0.9.6 the Revolution transport packages will be meaningless, you would have to create a separate download package and instructions for installing it in the legacy releases; even more work for the component developer.

As for determining the version of the core, this is reflected in both the system settings, and more officially via $modx->getVersionData() which returns an array with the following information (also fills $modx->version when called with this same array):

• version - The current MODx version. Revolution, after alpha-1, will always be version 2
• major_version - The current major release version, generally incremented when significant features are added or changed
• minor_version - The current minor release version, generally incremented when bug fixes are added without significant feature additions/changes
• patch_level - This reflects the patch release level, which would be empty for GA release, rc-1 for the first Release Candidate, alpha-3 for alpha-3 release, etc.
• code_name - This will be Revolution
• full_version - The full version string, e.g. 2.0.0-alpha-3; use this for version_compare() function as we follow PHP-compatible versioning guidelines
• full_appname - The product name + code_name + full_version, e.g. MODx Revolution 2.0.0-alpha-3

Quote from: OpenGeek at Jul 23, 2008, 11:56 AM

My instinct is that it will be better to create a Revolution specific version. Only the simplest of add-ons will make sense to author the same way for the new and legacy core, and by trying to make the more elaborate ones work in both, you will add further code complexity and quantity that will decrease it’s efficiency in both places.

That makes sene to me, especially for complex snippets like Wayfinder and Ditto, although I’m afraid it will mean that improvements and bug-fixes will be much less likely to make it into the legacy versions.

And since in 0.9.6 the Revolution transport packages will be meaningless, you would have to create a separate download package and instructions for installing it in the legacy releases; even more work for the component developer.

But this would be true either way if you want the improvements available for the legacy releases. With separate versions, you’d have that problem *plus* maintaining two separate versions of the source. And wouldn’t it be possible to create a module that would unpack and install transport packages in legacy releases?

Think also about maintaining separate threads in the Repository, Wiki, documentation, forum, etc. -- all more work for the component developer.

I know that with SPForm, I was able to make it work in both 0.9.6 and Revolution by adding a couple of if() statments and the documentation changes that let it support both versions took about 5 minutes. It’s in a transport package in that form and there’s also a zip file in the repository. EzFAQ was even easier since the same code worked in Revolution to begin with.

So, maybe we can just explain the advantages and disadvantes and leave it up to the component developer (though I’m not sure where the explanations would go)?

Quote from: BobRay at Jul 23, 2008, 12:57 PM

So, maybe we can just explain the advantages and disadvantes and leave it up to the component developer (though I’m not sure where the explanations would go)?

Agreed BobRay; ultimately you can create version independent add-ons and manage the complexity of developing that add-on. Maybe we can even come up with and share some tools to help reduce that complexity as you alluded to (Revolution package installer for 0.9.6, etc.).

I just imagine my focus will be on the Revolution way and some of the differences in key components like Ditto and Wayfinder IMHO should be maintained as a separate branch anyway. But these key components will become what I am referring to as "reference" components that will be following certain MODx Team standards for development that will make it easy for us to maintain branches of each for any target MODx core release via subversion (including future, and potentially all past, present and future 0.9.6.x releases as well).

Quote from: BobRay at Jul 23, 2008, 12:57 PM

That makes sene to me, especially for complex snippets like Wayfinder and Ditto, although I’m afraid it will mean that improvements and bug-fixes will be much less likely to make it into the legacy versions.

That’s likely going to be the case in due course, just like you don’t see a lot of plugins being developed for Adobe Photoshop 8 any longer. However, I think that the plugins that are functioning in the Evolution code base are pretty darned robust and useful as it is. Maintaining feature parity is just not likely to be a key focus, but I do suspect that bug fixes and security patches will find their way back into the "old stuff". Even then, I think we’re talking quite a number of months at the minimum, and that’s after Revolution is declared a stable release.

In short, I’m not too worried about it and am looking very much forward to having that problem!