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