Flexinode update

After my attempt to kill certain rumors around flexinode, I got quite some mails from people asking me “but what is the status”?Well, anyone who did his or her homework, would not ask that question, but would run away in terror. Anyway, here is the answer:Flexinode never really worked on 4.7, not according to my standards anyway, yet it was released before I took over and I decided to keep it released and mop up the mess as much as I could. And no, its not abandoned, it is simply swamped in issues, so much that adding your bugreport to that heap will not get it fixed: duplicates, people copy-pasting error-logs and then never coming back with more info, etceteras. There is too much in that queue to actually work on getting anything solved in there.

This made me decide to work on a entirely new 4.7 release alltogether. So before we are going to have an even worse hacked up 5.0 release, buit on top of the mess we already have, I want a clean 4.7 release. In order to achieve that, I created a group to manage all the efforts. But I also did some coding: I ripped some obsolete functions from the code (there were actually three functions, in total covering 120 lines of completely unused code!), and i split flexinode up in three parts: an admin module (can be disabled on production sites), a miniviews module, nothing (yet) to do with views, it simply contains the tables, search teasers and RSS feed pages, plus supporting code. And the core, flexinode.module.

I -personally- think we can have a release without the miniviews. That part is completely broken anyway, but if you really need it, this is the time to fix that part: the code is now isolated, so the effort should not be too hard. With this split-up, I introduced new issues, that I am sure of, so please test and debug. If you are using flexinode, or plan to do so, you should help yourself, by helping us: Instead of asking what the status is, or what the plans are, you can sift trough the numerous issues. That way you can find out what parts have issues and what parts don’t. While doing so, you can close duplicates, or mark silly features as won’t fix.

And then, finally, the Grand Plan. After the 5.0 release I want to rewrite some parts of flexinode, so as to improve performance, make it use normalised tables and to work towards the ideal fields and node system. But first, I call a general feature stop for flexinode. 1. First we must clean out all the code and remove broken fields.1. Then fix all critical bugs.1. Then fix the upgrade path from 4.6 to 4.7. 1. Once stable, a 4.7-2.0 release will be brought out. and a 5.0 branch is opened.1. Then I will start committing patches to prepare for a 5.0 release.1. __Once stable, a 5.0-1.0 release will be brought out.__1. Then new features make a chance of getting in, with the main aim not to add new features, but to work towards a better modelled flexinode!Can we count on you?