On Mon, 28 Apr 2008 19:46:09 +0200 "Daniel F. Kudwien" <news@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