| Project: | Elysia Cron |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
EC's method of using the exact same files in all three major development branches, with conditionals in the files to enable code for each branch, is highly unorthodox. We should really try to conform to the Drupal standard for usage of branches, and maintain separate versions of all files for the different branches (and while we're add it, probably stop supporting the 5.x branch, as per Drupal guidelines)
There are several benefits of switching to the proper system- it will reduce code complexity, encourage outside developers to contribute (since they can write a patch for just one branch without having to use conditionals and other hacks to make it compatible with all three branches), and reduce unnecessary cruft in users' installations (if I have a D6 install using EC, I don't want to have D7 code taking up space in the files!)
Additionally, it's impossible to conform to Drupal's coding standards using the current system, since the code standards differ between major core versions.
I'm happy to take on this task and submit a patch, as long as you support this change in principle.
Comments
#1
Here is a patch to the 6.x-1.x branch, please let me know if you support this and I will do more extensive testing and supply a 7.x patch. Otherwise, I'll fork EC into a new project.
#2
As usual, I forget the patch...
#3
Sorry for the late answer.
I've seen only now that you have posted a patch (i wrote this answer before seeing it...)
---
The method that Elysia Cron uses to separate code versions is a way to semplify coding, from my point of view, used in several other Drupal projects.
It consists in a "bridge class" (elysia_drupalconv), that is NOT shared between code versions, that permits to have a main line of code that is shared.
Some other file in the package are not shared (install file), or are naturally shared because have nothing to do with Drupal (scheduler).
In this situation there there should be no "unnecessary cruft in users' installations".
It's true that in main line of code there are some version conditionals. Not too much (mainly for queries), and i should delete them. (I'll do it when the queue of priority issues will be empty ^_^).
Consider also this:
- next major version will have a D5 release: several users asked me for it, and even i should continue using D5 in some of my sites.
- main features of Elysia Cron should be in all Drupal versions. So if someone will post a patch to fix some bug, or to implement some major features, that patch MUST be ported in all other versions.
This means that someone else (=me) will convert it.
This style of code semplify this task (for me).
- Elysia cron is not a visual module with a lot of rendering, doesn't use a lot of database or other features that are a lot different between Drupal version. It mainly hooks in cron layer, that is not changed so much between versions. The difference between code versions are not too much, and i think that in this situation there are no reason to have 3 branches of code completely separated.
It will encourage to leave bugs on older releases, or to have improvements only in some of them, with no real reasons.
Said that, now my major priority is to release a new stable release (the last one is dated 2009!!!).
This stable release will remain with this style of code.
I should release it very soon (i think a couple of weeks).
After that i can consider dropping the D5 version, and i can reconsider this situation... but i give you no promise about it ;)
If you want to fork Elysia cron to follow your needs about code separation, feel free to do it. More info about that in other thread...