[development] RFC: drupal as a moving target

[Ivan Sergio Borgonovo]

On Mon, 28 Apr 2008 19:46:09 +0200
"Daniel F. Kudwien" <news at unleashedmind.com> wrote:

> > That doesn't mean core have to stop to be revolutionary on 
> > some aspect but that new needs should be taken into account 
> > when deciding what to change, how fast and how.
> > 
> ...
> > If you change 3 different parts of the API in one round, 
> > porting modules will be a harder task than if you concentrate 
> > on making one part of the API really really nice so that it 
> > won't have to be touched soon. Changes will still be radical 
> > in terms of improvement but porting may become an easier task.
> 
> Please correct me if I understood you wrong, but I think you're
> arguing for backwards compatibility in Drupal's APIs.  This has
> been discussed several times before and the arguments are still
> valid:  Ensuring backwards compatibility would lead to unnecessary
> overhead in the source code and longer development cycles.

I didn't say ensuring backward compatibility I wrote going beyond the
"we won't care phase" to a "we will take it into account".

Furthermore the fact that it has been discussed in the past doesn't
mean that it can't be discussed now as implicitly Dries seems to
suggest:

"I feel that preserving the ability to constantly innovate is of
higher importance, *at the present time at least*, than preserving
backward compatibility."

DB API, menu API are good examples. DB API is not mature enough to
think it can be left as it is.

Drupal is more mature, more diffused, more more... it is changing,
also thanks to the previous policy. But well you can't apply the same
recipe to new ingredients and the balance between return from fast
change and stability is naturally moving towards stability... for
many reasons... accompanying the process consciously will make it
smoother. That doesn't mean APIs are engraved into stones... it just
mean that changes should be managed in a way to take into account the
changing status of the project and the needs of the users.

Again... big shops may still find manageable those API changes,
smaller shops may find it hard... but smaller shops contribute to
Drupal too, they are a resource as well... and missing some planning
for smoothing API changes will especially damage the one that are
developing complex modules that have a long development time.

Giving a more guided pressure on contrib may end up in keeping up the
good continuous stream of quality modules that require more time to
be ported than the 300 lines stuff and gaining market share as well.

Actually the support cycle went from 6-12 months to 12-24 months in
the last year. We have SimpleTests... that will have an impact on
release cycle phases too. It could be an option to have "shorter"
release cycles with smaller changes in the API, or there could be a
policy to concentrate the efforts on fewer but better API changes so
that every single aspect of the API will change less frequently but
more radically... etc...

Seriously, I'm not here for a religious war and I do see gray shades,
not just black or white.

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it