[development] RFC: drupal as a moving target
jpetso at gmx.at
Tue Apr 29 10:24:00 UTC 2008
On Tuesday, 29. April 2008, Ivan Sergio Borgonovo wrote:
> Is it mature and complex enough that API don't have to be changed
> twice in a row for the same functionality, so that changes for
> each releases will impact just few aspect so that can be easier
> managed during an upgrade cycle?
Ivan, I feel your pain, I'm having a hard time with porting my modules in time
as well (in addition to "new features" work). The problem does exist.
However, what I miss from your mails is a constructive proposal how to make it
better. Even now, the APIs are not changed for the fun of it but always come
with a significant improvement. You request that the core devs take care not
to change stuff *without a good reason*, but that's what they do already.
So the question is if you want to have the APIs freezed even if there would be
a good reason to change them, and *that* is what the policy applies to.
Do you want to have some of those APIs freezed as well? Possible answers:
"No, because they do indeed make Drupal better, even if it causes more effort
In that case, we're at the status quo, and the discussion is over.
"Yes, because the cost of upgrading is more important than the cleanest
possible Drupal core."
In that case, you disagree with the community (including me), and we expect
you to make concrete proposals which type of API changes should be frozen
under which exact circumstances, and present compelling arguments why that is
better than the status quo.
You argued that Drupal is becoming stable and mature enough to freeze some
aspects of the API. If that is the case, I believe that no more API changes
will be written up for these areas, and the problem will be solving itself in
time. However, I believe that Drupal has still years to go until it reaches
that state of maturity, and that each API change causes more good than harm
in the end.
If you believe that some of the changes from Drupal 5 to 6 caused more harm
(in terms of slowing the upgrade process) than good (in terms of consistency,
long-time maintainability and important features), then by all means,
"show us the code".
Which changes would better have been left out in your opinion?
I'm keen on seeing examples from you, because the process can only be changed
if we recognize what actually went wrong. If you can't find good examples,
then this whole discussion is moot because there's nothing to complain about.
More information about the development