[development] How to port modules? was: Drupal 7 "When it's Ready"
Matt Farina
matt at mattfarina.com
Thu Mar 5 12:16:48 UTC 2009
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 at 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
>
More information about the development
mailing list