[development] CVS HEAD, code freeze, zeitgeist
ber at webschuur.com
Fri Aug 18 12:34:15 UTC 2006
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.)
> lexinode isn't going to be ported to either 4.7 or 4.8 (according to
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
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
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
> 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
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?
More information about the development