[development] CVS HEAD, code freeze, zeitgeist
dries.buytaert at gmail.com
Fri Aug 18 13:32:05 UTC 2006
> Yes. In fact, I beleive the only solution is the other way around:
> 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
> If stuff (contribs) is not ready, we should not tell people to
We had this discussion before, and I still disagree. I believe that
CCK+view is what the next generation of open source CMSes will look
like. They have the potential of being the heart of Drupal. For
Drupal to get to the next level, they have to be in core so that
everyone can rely on it as well as build on it.
> 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.
Please elaborate. What would you rewrite, and why? What is not
properly done in core that is a showstopper for full CCK support?
> 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.
> another release without a production-ready system for dynamically
> build (with
> fields) nodes.
Note that there are 3 systems here: (i) flexinode, (ii) contrib CCK
and (iii) core CCK.
I can't speak for (i) or (ii) but if they are "hacked up" then their
maintainers are to blame -- at least to a certain extend. I can only
speak for (iii), and I think you're overly pessimistic about it.
1. We made an almost insane amount of progress since Drupal 4.7,
and we might make more progress by the time we freeze the code. (Go
2. The lightweight CCK that is in core is fully functional. Sure,
you can't add extra fields yet but there are many valid use cases
where you don't need additional fields.
3. It is probably at least another 2 months until Drupal 4.8/5.0
gets released. That means that there is plenty of time left to fix
(i) and (ii), and to a lesser extend (iii). It's only 3 months since
we released Drupal 4.7, and it is another 2 months until we might
release Drupal 4.8/5.0.
4. The work we have done in CVS HEAD should be beneficial for (i)
and (ii) so I'd like to believe that these modules become less
> 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
> 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?
I've seen some pretty cool things that would not have been possible
with Drupal 4.6. Drupal 4.7 certainly allows more feature-rich
modules to be built. I've also seen modules that take advantage of
Drupal 4.7 functionality to improve the user experience. As such, I
disagree with your point about feature-richness and wrote about it
It's true that certain projects are slow catching up but that is
because Drupal 4.7 was such a big change. Drupal 4.8 will be much
easier to deal with, and will be less disruptive. Again, I think
you're somewhat pessimistic:
drupal.org/htdocs/files/projects $ ls -als *-4.6*gz | wc -l
drupal.org/htdocs/files/projects $ ls -als *-4.7*gz | wc -l
There are more 4.7 projects then there are 4.6 projects (and 4.6 has
been around for a much longer time).
Dries Buytaert :: http://www.buytaert.net/
More information about the development