[development] CVS HEAD, code freeze, zeitgeist
gabor at hojtsy.hu
Fri Aug 18 09:08:09 UTC 2006
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
More information about the development