[development] CVS HEAD, code freeze, zeitgeist

[Gabor Hojtsy]

On Fri, 18 Aug 2006, Richard Archer wrote:

> How about doing with CCK what was done with the Forms API...
> commit CCK to core, freeze all the other features and then
> make CCK work properly.
>
> That way the feature set for 4.8 is known and people can
> begin porting their contrib modules, none of which will
> rely on CCK (although some may benefit from it in the
> long term).
>
> And since CCK will take a couple of extra months to fully
> debug, there will be sufficient time to port modules.

It was decided that we are not going to go down on the same route again, 
as we have done with the FormsAPI. People need reliable release dates and 
solid features fast. If CCK is not going to be updated for 4.8/5.0 to get 
compatible with the custom content types in core, it just shows that there 
is no interest. In case there is voluntary or financial interest in doing 
a flexinode upgrade path or a CCK update and upgrade path, it will happen.

I have first hand experience with some of my module creations I was 
reluctant to update. People came up with patches, and since I had no time 
to review and apply them, I handed over maintanance. Sometimes I peek into 
their current state (I might need them for ongoing projects), and some of 
them already changed to another maintainer, but as long as there is need 
for them, they keep getting updated.

Contrib modules, translations, themes need time for sure. If we keep 
pushing the freeze date, most contribs, themes and translations will push 
their update dates further. If interface strings are not stable, why 
should I bother translating them? If the database structure / API is not 
stable, why should I bother to update my modules for that API / database 
structure? If it is uncertain how themes will get handled in the next 
Drupal version, why should I bother updating my themes? You see, putting 
some big change into core which makes for an uncertain freeze date and 
still a lot of changes onward is not helping contribs update.

The fact that CCK HEAD is not yet compatible with Drupal HEAD does not 
mean anything for the future. If I were the CCK maintainer, I would not 
care updating my module either until I see the solid codebase to update 
to (and this is what I do with my current maintained modules and the 
Hungarian translation).

Gabor