On the documentation side of updating there is http://drupal.org/ update. If you are talking about modules see http://drupal.org/update/modules . Also note that, a number of module maintainers (for widely used projects) have openly said they would like to release versions of their modules when drupal 7 is released. Dries, also, said that releasing drupal 6 without drupal.org being updated to it was a mistake he doesn't want to see happen again. I would be careful about trying to legislate anything. Let's see how the community responds. It might be good to get a movement of maintainers to update their modules for drupal 7 when a good time comes for that (like after the code freeze). I think that would be better received and more likely to make a difference. On Mar 5, 2009, at 4:08 AM, Ivan Sergio Borgonovo wrote:
On Wed, 4 Mar 2009 20:06:14 -0500 Khalid Baheyeldin <kb@2bits.com> wrote:
So far, it has proven to be an acceptable price to pay for innovation. Yes, it causes some pain, but if we fix the APIs
I think some more attention should be put on "so far".
I never read a book on software development that suggest that writing from scratch is a good strategy but I admit having felt the pain of refactoring quite frequently I've read more books on how to fix the problems rather than how to get involved in a completely new set of problems ;)
It could be that this is going to be part of drupal nature... since it is a tool for a still very dynamic environment where the set of problems change quite radically... but still... I wouldn't take it for granted that drupal development life-cycle and nature is going to be the same as it has been in the past. For the same reason I consider the argument of "let's stabilise the API" a legit argument as well... and it is just a matter of balance and context. I think the evolution of how fast API are going to change will follow the evolution of how much core is an application vs. a framework. I think one of the secret for success of drupal has been being halfway between a self sufficient application and a framework. This is a ideal spot for small to medium projects where you can add value with some tuning and the cost of rewriting is lower than the cost of missing a large improvement made to core. But the space for small shops is shrinking and the complexity of the overall drupal project is increasing. I wouldn't take for granted that the sweet spot is always where it used to be and factor in as much elements as I could to make a forecast. Maybe core devs belongs to "subset" of drupal community that has "its own itches", but the efforts of core to "scratch their own itches" may not be the best compromise to scratch the "collective itches" of the community that is *evolving*. I'm not saying that core devs are blind or insensible to community needs, I'm just saying that it's better to take nothing for granted and somehow this kind of discussions aren't pointless just because they are repeated.
Panta rei.
Orchestrating for this is one of the most valuable targets of software development especially in Open Source projects.
Better focus on tools that would make migrating your modules easier/quicker (core, deadwood, documentation for converting from 6.x to 7.x, ...etc.)
Awesome. I've found http://drupal.org/project/deadwood That was easy. What were you referring to with "core"?
Do you have any other pointers to tools, docs, secret recipe, everything that will help to port modules?
I was just planning to write my own tool at least to spot changes in signatures.
Are there any coding standards that could make porting easier? Core dev strategies that could make any change easier to digest?
Maybe Kyle Mathews is right and we just need to try and all the tools, docs and efforts from the core team to make transitions as smooth as possible are already there... but is there some further knowledge, tool, strategy that could be deployed? Or just a linden tisane?
thanks
-- Ivan Sergio Borgonovo http://www.webthatworks.it