[development] CVS HEAD, code freeze, zeitgeist

[Dries Buytaert]

> 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.

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.  
> Result:
> 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  
folks, 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  
"hacked up".

> 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?

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  
earlier:

   http://buytaert.net/the-pain-before-the-payoff

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
   461

   drupal.org/htdocs/files/projects $ ls -als *-4.7*gz | wc -l
   484

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/