Re: [development] 'old' core 6 & new 7, working together..? +crossite
Hi there, Some arguments here are not completely true. Look here how developers spend much time on new issues for core 5 ! http://drupal.org/project/event It's only an example & there is more; this is a clear statement that some developers prefer to spent time on getting 5 better, instead of getting all other lacking modules from 5 to 6, so website owners don't have any reason left to step over from 5 to 6. Waste of time? Yes, one can pay for development. But who is gona pay me for my volunteer work? Many sites are social sites, or small to medium commercial ones. It will cost an enormous lot of money to pay for custom made modules at programmers fees. The smaller social ones that can, have to rely heavy on subsidy and that money can change the social movement in the political and even corrupt direction of the money givers. So I pay for myself, above my volunteer work that ofcourse doesn't generate money to invest in this social network. That situation won't change that easy in a few years. Drupal programming is a blend of non-centralised volunteer work with some agreements through negotiations, and commercial driven projects (even the social ones, if they can arrange money). That's its power, but also its weakness. The positive effect for introducing core 7 in the first year, will maybe lay only in a wake-up call that some modules from 5 can't wait anymore to be transformed to 6, so MAYBE in a year from now websites have no rason left not to stick with core 5 anymore. But for core 7 to run on most drupal installations, will take 2 years? Two years before a development can be practically implemented, is an ENORMOUS waste of time too. So most like to have a core 6 AND 7 website (or even with a 5). But -except for quite simple/basic sites- nothing can be transformed to the 7 website, because there is no integration AT ALL. Not even automatic login for all members of the 6 site? Hey guys & girls; wake-up; most want such a smooth transition. Yes, I understand that bridging and integrating all aspects COMPLETELY, will be an insane waste of time. But what can be bridged PRACTICALLY? (again; I'm not suggesting bridging everything, what indeed would be a waste of time) And can/needs core 7 be revised before the first release, to make bridging less complex? Ofcourse without touching the pro's of core 7. Then I'm not only suggesting what the title says; bridging in general WITH NON DRUPAL programs/sites, is a hot item. Ofcourse not everything is practically possible in bridging. BUT: If the core 7 uses some standardised coding (lack of a standard?), it will be easier to bridge to other programs that use the same standard. So the same work to (partly) bridge 6 to 7, as well as to (partly) bridge 7 to many other programs and sites. All in one basic bridge module/API, implemented on a possible re-written core 7 for more standardisation in these. ABOVE this basic bridge API for core 7 only, specific bridges like core 6, Twitter, Facebook, Mediawiki, social networks, Google Wave: http://code.google.com/apis/wave/ , etcetera. Maybe even 'copy' Google Wave standards into a Drupal API ? If Drupal looses this development, a lot of sites and people might migrate from Drupal to Google,not now, but somewhere in future. Another argument here is that Drupal programmers aren't interested in bridging, mostly because of some unnecesary experiences to bridge to some specific fora. Well, thats old school; there are many new developments and trends... Most Drupal programmers have a good general education and understanding of social issues too. One needs to realise the so called "cultural barriers", withdrawing in subcults, For example: Is the way Mediawikis think wrong, or how Drupals think? They both think in their own same street/culture. But to get to a higher culture, one needs to think how the other thinks and then make some general thinking that is good for both. Also getting a culture to a higher or another culture, will always meet enormous tense resistance. They will kill the first sheep that dares to walk over the dam. If they kill the first sheep, the power balance is back to the old culture. But if the first sheep is very stubborn and succeeds inspite of all the resistance, then slowly others start to follow and met lesser resistance, untill the mass starts moving towards the other culture. But its very difficult, even if the other culture has many more advantages for all. In filosophy cultural study there is something like this in other words, I forgot the official terms. Anyway, all the best.
From my understanding any project using drupal 5 once drupal 7 is out will be in the cold as that is when I expect the support for drupal 5 to be discontinued.
All the time that it will take to support drupal 7 to co exist with drupal 6 would be better spent porting the drupal 6 versions to drupal 7.
The "event" module is actually a great example of why the current system works. Event hasn't been upgraded -- not because it was too hard to upgrade or because "developers prefer to spend time on getting 5 better instead of upgrading modules". It hasn't been upgraded because "Event", as a module that solves the "I-want-to-store-and-display-dates" problem, has been entirely superseded by the cck/date/calendar/views stack of modules. *Nobody* afaik uses the Event module in Drupal 6 just because cck/date/calendar/views is so clearly superior. It's much more flexible because date is a cck field, "date" nodes" have excellent and extensive integration with Views, and the Calendar module provides again a powerful and flexible method for displaying "date" nodes in a calendar format. I've used both setups, Event back in my Drupal 5 days, and cck/date/calendar/views more recently, and the two solutions don't even compare. To borrow a biology metaphor, Drupal is evolving rapidly year after year and some modules/module-stacks such as Event prove to be evolutionary dead-ends. It does suck I agree (having done it a number of times) to have to migrate data between module setups -- everyone would prefer easy migrations -- but giving the environment Drupal lives in, the web, that's not going to happen for a long long time. Maybe when the web becomes stable and boring, Drupal will also become stable and boring. But in the meantime, we have to race to keep up. --Kyle Mathews kyle.mathews2000.com/blog http://twitter.com/kylemathews On Wed, Jan 6, 2010 at 6:45 AM, Ad <cyb.org3@yahoo.com> wrote:
Hi there,
Some arguments here are not completely true. Look here how developers spend much time on new issues for core 5 ! http://drupal.org/project/event It's only an example & there is more; this is a clear statement that some developers prefer to spent time on getting 5 better, instead of getting all other lacking modules from 5 to 6, so website owners don't have any reason left to step over from 5 to 6. Waste of time?
Yes, one can pay for development. But who is gona pay me for my volunteer work? Many sites are social sites, or small to medium commercial ones. It will cost an enormous lot of money to pay for custom made modules at programmers fees. The smaller social ones that can, have to rely heavy on subsidy and that money can change the social movement in the political and even corrupt direction of the money givers. So I pay for myself, above my volunteer work that ofcourse doesn't generate money to invest in this social network. That situation won't change that easy in a few years.
Drupal programming is a blend of non-centralised volunteer work with some agreements through negotiations, and commercial driven projects (even the social ones, if they can arrange money). That's its power, but also its weakness. The positive effect for introducing core 7 in the first year, will maybe lay only in a wake-up call that some modules from 5 can't wait anymore to be transformed to 6, so MAYBE in a year from now websites have no rason left not to stick with core 5 anymore. But for core 7 to run on most drupal installations, will take 2 years? Two years before a development can be practically implemented, is an ENORMOUS waste of time too.
So most like to have a core 6 AND 7 website (or even with a 5). But -except for quite simple/basic sites- nothing can be transformed to the 7 website, because there is no integration AT ALL. Not even automatic login for all members of the 6 site? Hey guys & girls; wake-up; most want such a smooth transition. Yes, I understand that bridging and integrating all aspects COMPLETELY, will be an insane waste of time.
But what can be bridged PRACTICALLY? (again; I'm not suggesting bridging everything, what indeed would be a waste of time)
And can/needs core 7 be revised before the first release, to make bridging less complex? Ofcourse without touching the pro's of core 7.
Then I'm not only suggesting what the title says; bridging in general WITH NON DRUPAL programs/sites, is a hot item. Ofcourse not everything is practically possible in bridging. BUT: If the core 7 uses some standardised coding (lack of a standard?), it will be easier to bridge to other programs that use the same standard. So the same work to (partly) bridge 6 to 7, as well as to (partly) bridge 7 to many other programs and sites.
All in one basic bridge module/API, implemented on a possible re-written core 7 for more standardisation in these. ABOVE this basic bridge API for core 7 only, specific bridges like core 6, Twitter, Facebook, Mediawiki, social networks, Google Wave: http://code.google.com/apis/wave/ , etcetera. Maybe even 'copy' Google Wave standards into a Drupal API ? If Drupal looses this development, a lot of sites and people might migrate from Drupal to Google,not now, but somewhere in future.
Another argument here is that Drupal programmers aren't interested in bridging, mostly because of some unnecesary experiences to bridge to some specific fora. Well, thats old school; there are many new developments and trends...
Most Drupal programmers have a good general education and understanding of social issues too. One needs to realise the so called "cultural barriers", withdrawing in subcults, For example: Is the way Mediawikis think wrong, or how Drupals think? They both think in their own same street/culture. But to get to a higher culture, one needs to think how the other thinks and then make some general thinking that is good for both. Also getting a culture to a higher or another culture, will always meet enormous tense resistance. They will kill the first sheep that dares to walk over the dam. If they kill the first sheep, the power balance is back to the old culture. But if the first sheep is very stubborn and succeeds inspite of all the resistance, then slowly others start to follow and met lesser resistance, untill the mass starts moving towards the other culture. But its very difficult, even if the other culture has many more advantages for all. In filosophy cultural study there is something like this in other words, I forgot the official terms.
Anyway, all the best.
On 8:59 PM, Ad wrote:
website owners don't have any reason left to step over from 5 to 6.
If you are not a Drupal development company, then you have to switch from Drupal 5 to Drupal 6 now. There is no excuse for not doing it.
Actually I would say that doing 5->6->7 all at once is a valid approach. You cut down on testing, since you have one fewer live push. You also don't have to worry about replacing a module twice (first doing a difficult to transition to 6 and then months later rewriting it again -- just rewrite it in 7 once). - Ken Winters On Jan 7, 2010, at 2:22 AM, Csuthy Balint wrote:
On 8:59 PM, Ad wrote:
website owners don't have any reason left to step over from 5 to 6.
If you are not a Drupal development company, then you have to switch from Drupal 5 to Drupal 6 now. There is no excuse for not doing it.
You can of course do both at the same time, first jump from 5 to 6, make sure things are working right, and then jump from 6 to 7. But I just want to clarify, in case there was any confusion, that you can't just 'skip' the in-between version. And you can skip pushing it live but you can't skip testing it. And if you need to do it anyway, IMO it is actually easier to do it now, make sure everything is working smoothly in version 6, and then do the 6->7 jump later. There are many modules (like CCK) that will need to be upgraded from 5 to 6 before jumping to 7, especially when there are data updates and schema changes involved. It's time-consuming to write and test update hooks, it's a huge burden on developers to keep updates working for even one version back, let alone two. CCK had massive changes between version 5 and 6, we had to drop any support for taking people from 4.7 straight to 6, and even then were many situations where the upgrade didn't immediately work smoothly and admins had to do some tweaking or get help with site-specific issues. There will be even more massive changes from 6 to 7. We're committed to creating an upgrade path from 6 to 7. There will be no one writing or testing upgrade paths from 5 to 7. The other issue is that D5 is less and less well supported as time goes by, so you may be stuck for support until you are ready to jump to 7, whereas support for D6 is good. As you point out you can avoid re-writing your custom modules for the in-between version, assuming your site works well enough without them to test other module upgrades. If you have a lot of custom code that may be a valid reason. But all the changes from D5 to D6 are mostly still needed and used in D7, so you still need to figure out what they are. I personally think any time you save in one place by skipping a version will be made up elsewhere in time spent figuring out what broke and how to fix it, but each to his own on that issue :) Karen On Thu, Jan 7, 2010 at 7:57 AM, Ken Winters <kwinters@coalmarch.com> wrote:
Actually I would say that doing 5->6->7 all at once is a valid approach. You cut down on testing, since you have one fewer live push. You also don't have to worry about replacing a module twice (first doing a difficult to transition to 6 and then months later rewriting it again -- just rewrite it in 7 once).
- Ken Winters
On Jan 7, 2010, at 2:22 AM, Csuthy Balint wrote:
On 8:59 PM, Ad wrote:
website owners don't have any reason left to step over from 5 to 6.
If you are not a Drupal development company, then you have to switch from Drupal 5 to Drupal 6 now. There is no excuse for not doing it.
-- Karen Stevenson Lullabot.com
Really the D6 step in the middle doesn't have to "work" at all if you aren't going to push it live. The middle step is just so that your data migrates as best as it can. All the display code, etc. that uses the data doesn't have to work right, and that means much less to test and fix. None of the D6 code will still be in use when the D7 site goes live anyway, and I believe that the total work needed will be lower this way in the majority of cases even after accounting for problems you might have discovered in D6. Use latest D5, update.php, switch to D6 core and latest modules where possible, update.php, switch to D7, update.php. You're correct that many modules will not support a direct 5->7 upgrade path, and often you need to use the newest D5 branch to successfully migrate to D6. A lot of your site is going to break, but that's unavoidable and at least it won't break twice. The best reason for moving to D6 now and pushing it live is if you *really* need something that D6 offers and can't wait a few more months, but chances are good that you moved to D6 long ago if that was the case. If your site is D5, I'd also consider using the opportunity to just build a new site instead of trying to migrate. Lots of things that made sense in the D5 era have been completely replaced now, and you're already going to be doing a ton of work and testing. The data you want to keep can be imported (nodes, etc.). - Ken Winters On Jan 7, 2010, at 12:02 PM, Karen Stevenson wrote:
You can of course do both at the same time, first jump from 5 to 6, make sure things are working right, and then jump from 6 to 7. But I just want to clarify, in case there was any confusion, that you can't just 'skip' the in-between version. And you can skip pushing it live but you can't skip testing it. And if you need to do it anyway, IMO it is actually easier to do it now, make sure everything is working smoothly in version 6, and then do the 6->7 jump later.
There are many modules (like CCK) that will need to be upgraded from 5 to 6 before jumping to 7, especially when there are data updates and schema changes involved. It's time-consuming to write and test update hooks, it's a huge burden on developers to keep updates working for even one version back, let alone two. CCK had massive changes between version 5 and 6, we had to drop any support for taking people from 4.7 straight to 6, and even then were many situations where the upgrade didn't immediately work smoothly and admins had to do some tweaking or get help with site-specific issues. There will be even more massive changes from 6 to 7. We're committed to creating an upgrade path from 6 to 7. There will be no one writing or testing upgrade paths from 5 to 7.
The other issue is that D5 is less and less well supported as time goes by, so you may be stuck for support until you are ready to jump to 7, whereas support for D6 is good.
As you point out you can avoid re-writing your custom modules for the in-between version, assuming your site works well enough without them to test other module upgrades. If you have a lot of custom code that may be a valid reason. But all the changes from D5 to D6 are mostly still needed and used in D7, so you still need to figure out what they are.
I personally think any time you save in one place by skipping a version will be made up elsewhere in time spent figuring out what broke and how to fix it, but each to his own on that issue :)
Karen
On Thu, Jan 7, 2010 at 7:57 AM, Ken Winters <kwinters@coalmarch.com> wrote: Actually I would say that doing 5->6->7 all at once is a valid approach. You cut down on testing, since you have one fewer live push. You also don't have to worry about replacing a module twice (first doing a difficult to transition to 6 and then months later rewriting it again -- just rewrite it in 7 once).
- Ken Winters
On Jan 7, 2010, at 2:22 AM, Csuthy Balint wrote:
On 8:59 PM, Ad wrote: website owners don't have any reason left to step over from 5 to 6.
If you are not a Drupal development company, then you have to switch from Drupal 5 to Drupal 6 now. There is no excuse for not doing it.
-- Karen Stevenson Lullabot.com
participants (6)
-
Ad -
Csuthy Balint -
Karen Stevenson -
Ken Winters -
Kyle Mathews -
Naheem Zaffar