[development] 'old' core 6 & new 7, working together..? +crossite

[Victor Kane]

Take into account that when a module is not updated for a new core release,
its functionality has been included in another module, or else in views,
cck, or another of the major modules.

Also, in your architecture for sites, try to add new functionality on the
basis of a smaller set of very flexible modules, such as og, views, cck...
Many of the minor modules can be re-created out of a smaller starter set of
major modules.

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com

On Tue, Jan 5, 2010 at 10:39 AM, Ad <cyb.org3 at yahoo.com> wrote:

> (I tried to respond on a particular message, but don't know how)
>
> = = = = =
>
> Thanks for all the feedback. Ofcourse; backwards programming doesn't make
> sense. But I encountered several sites running on core 5, because there
> isn't even an upgrade for the mods they need to core 6, or only a
> preliminary one. I'm not going to make a report of what I encountered (last
> 4 days uploading many-many mods); probably all here are familiar with the
> problem.
>
> There are mods that have something about what I suggested, like this
> 'outdated' module I just encountered:
> http://drupal.org/project/crossite
>
> Many usefull mods are written for 5 and never updated for 6, see for
> example this hyper-modern site that untill now only can run on 5:
> http://drupal.org/node/342472
>
> So the question: what is outdated in these? Ofcourse the new core 7, not at
> all. But the whole package with the mods, will be literally outdated for one
> year, up to some years.
>
> Why not getting crossite running again, in a new and broader & standardized
> form, for both 6 and 7? Maybe even changing the 7 core before the definitive
> first release, to anticipate for this development & make some transitions
> smoother?
> ,
> IF SO:
>
> 1) one could run some parts on core 6 and others on core 7, for the first 2
> years untill almost all necessary mods are on 7. Everyone could migrate
> inmediately to 7, so it would be a step forward with a smooth transition,
> not backward;
>
> 2) The same system (updated) can in future also be used for 7 to 8, so its
> not a one time case and lost creativity;
>
> 3) Several other web-programs have some bridge with Drupal, but quite
> amateuristic and no broad development support to get the basic/general API
> ready for all of these specific bridges (, communicators, exchangers,
> integrators a.s.o.).
>
> It might be web-worlds future hype, or already is with integrating gadgets,
> cellphones, twitter, facebook, groups, mediawiki and so on. Mediawiki was
> partly running, but with new releases it stopped running again, lacking a
> protocol for both Drupal and Mediawiki. Yes, it is difficult to get the core
> optimized for this and make a sort of inter... protocol how programs best
> can bridge with as many aspects as possible. But because of the importance,
> to my opinion it should become a main developers community task to get done
>
> Do we still need to wait untill core 8 for such a development? Actually I
> had a test site on 5 and had to wait 2 years before not even all required
> modules were up to date. So I might start soon in 6, but I'm still missing
> some features from 5.
> If possible, I recommend to start working on bridging even before the
> release of 7, examining if there better needs to be changes in the basics of
> core 7 first, to optimise for an additional 'general bridge API'.
>
> My sincere excuses to all voluntary programmers; but succesfully learning
> how to program these mods, would cost me too much time. I better concentrate
> my volunteer work on building the social site with the mods & getting that
> project running. In doing so, I can check the latest dev's and feedback.
> Like who knows for example, if I encounter a problem for this 'new'
> preliminary dev securelogin:
> http://drupal.org/node/146238/release
>
> Good luck with core 7!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20100105/f0e9770b/attachment.html