Op vrijdag 18 augustus 2006 11:58, schreef Dries Buytaert:
The reality is that it will probably take another release to get it right, and that it will take several more releases to add polish. Of course, you never know. We still have two weeks left, and there is a lot that one can do in two weeks ... (It wouldn't be the first time this release cycle that Eaton, jaza or chx come forward with a big chunk of CCK code.)
And Derek
and lexinode isn't going to be ported to either 4.7 or 4.8 (according to ber)
flexinode is released for 4.7. But it is a crippled hasty release. I took it over a little too late (it was already branched eventhough nothing worked at all!). All the 4.7 has been about cleaning up this mess, and about getting around FAPI oddnesses. On 4.7.3 Drupal version, flexinode has a new critical bug again. All this to illustrate what I meant with the word "properly". Sure, big chance there will be a 4.8 version of flexinode. Also a big chance the 4.7 issues will be ironed out little more. so there are releases. But I talked about "proper" releases. When people say "cck is released for 4.7" that is about all they can say. Because there is hardly documentation, the code and database-architecture went trough rather big changes in the last months. There are virtually no really usefull fields (all are under development) and the usability of the admin interfaces needs lots of love too. It is simply not ready for production (IMO). What i meant with properly in my previous mails: Making a 4.6 module "work" in 4.7. Upgrading a module from 4.7 to 4.8 is not a lot of work. But doing that *properly*, by using the new core featues, by using better API's and by keeping up standards, often requires an almost complete rewrite. A good flexinode 4.8 would use the core dynamic node features. A good flexinode 4.8 would use views instead of its own private limited views code. Anything else then that, I consider a hack. Yes, it might work, probably be be released for 4.8, but it is certainly not something to be proud of as Drupal community.
It is dangerous to postpone the code freeze in order to get more stuff in core: it takes time to implement this, and as far as I know, no one is currently working on a patch to get basic field support into core.
Yes. In fact, I beleive the only solution is the other way around: Release with less stuff in core. The less changes, the easier it is to keep in pace with all our contribs. And in the same time, put less pressure on upgrading. If stuff (contribs) is not ready, we should not tell people to upgrade. This particular field feature, however requires a big rewrite for CCK, again. If CCK would do it *properly* (see above), it would mean a big rewrite to remove of one of the core concepts in CCK: making nodes. I suspect this might mean a complete rewrite, after all. So this leaves us a long period in 4.8 with 1) a hacked up, patched up flexinode and 2) a heavy under development replacement for it, CCK. None of wich I would advice any (sane) person on his/her production site. Result: another release without a production-ready system for dynamically build (with fields) nodes. I don't see this as a reason for postponing a code freeze. But I do see this as a reason for concern in a more general way. Especially since the problem seems to become structural. with the rapid growth of Drupal one would expect the overal quality, amount and feature-richness of contribs and themes to improve. I don't see this happening ATM! discussion at drupalcon? Bèr