[development] CVS HEAD, code freeze, zeitgeist

[Bèr Kessels]

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