Flexinode bug list now resembling reality...
The list of flexinode issues has shrunk a lot. I closed about 30 per day, and think I have now got a list with bugs that actually exist, or need to be confirmed.
A dynamic up-to-date list is here. By time of writing it were 25 bugs left for ‘core fields’ and flexinode itself.
Once we’ve got them sorted out (I expect half of them don’t need patches, but are simply related bugs, duplicate that are poorly described or errors on the side of the one reporting), we can release a real 4.7 version. After that, its on to a 5.0 release. From there on the real work on a simplified, well architecured version can start. Woo.

Wonder if you can enlighten
Wonder if you can enlighten me. Here is where I’m currently at: 4.6 is now EOL since they released 5.0. Therefore to keep something supportable (security-wise), I need to upgrade.
Currently, I’m using flexinode (specifically for event in my case). Given that I’m using event, and it’s not ready for 5.0 yet, I’ve basically got to look at 4.7. Should I be upgrading to 4.7 with the existing flexinode now (with any breakages that this might entail?), or trying to hold off a bit for the real 4.7 you’ve mentioned above? Is it possible that the real flexinode 4.7 will break event 4.7, or have you by chance tested this (I’m guessing yes, but it never hurts to ask)?
I know I could technically move to CCK (since event will use that), but since it’s still changing a bit, I think I’d rather see where flexinode goes first. I’m guessing that upgrading between versions of flexinode is going to be less painful than migrating to CCK (not that I actually need to preserve any of the old event entries anyway, so in either case I’ll probably be dropping them all and starting clean if possible).
Suggestions of any sort welcome.
Take care.
A very general, yet good
A very general, yet good description of flexinode is:
betterdifferent. :)For you, I’d say that upgrading to the now-released 4.7 is safe. The only thing you should do, before upgrading, is make sure, very sure, that the fields you need actually work. The biggest problem in the current 4.7 ‘release’ is that a lot of fields were not tested (or not even upgraded at all) for 4.7.
My main aim with the ‘proper’ 4.7 release, is to streamline that upgrade a bit better. To digg trough all the fields and weed out the unmaintained and broken ones and to pinpoint the critical fields. To make really certain that Real-World databases don’t break. Not just “meh, my two ‘asdfhjkl’ posts were upgraded, let’s release.”
That gives me a much clearer
That gives me a much clearer understanding of things. Thanks muchly.
I’ll move all the data to a test system and give it a shot.
Well done
Goed bezig man! ;-)