Hello Uberland,
Now that Beta 2 of Drupal 6 has been released, what are the plans to port Ubercart to Drupal 6?
Any ideas what areas of the ubercart code will need updating? Are there tools out there to assist with the upgrade?
Jeff
Drupal 6!
I had no clue the list was up to 70!!! Good gracious!
In other news, there is the coder module which provides some helps for updating modules. Can't say I'm looking forward to the process, but I'm definitely looking forward to the results. 
I'd love to see us implement the visualize backtrace module, too.
I'm about to start a Drupal 6 site, and will need to update UC for it.
What can I do to help get a 6.x UC? I'm willing to do the bulk of the work if necessary, and it'd help everyone (including me!) if I had your blessing, and perhaps a 6.x tag in CVS 
Just tell me what to do and I'll get started
Cheers,
Ben
Ben, this is music to my ears, but it may be a little premature, as we still have some bugfixes and things to address before moving onto 6.x. The gameplan was to get to 1.0 and then move over, so we wouldn't have to worry about duplicating fixes and things. Since we're not really doing anything based off patches, it'd be kind of hard for someone else to duplicate our fixes.
What's your timeline looking like to roll the 6.x site out?
Ryan, we're looking to start development within the next few weeks, with a view to completion in about 2 months.
I understand the difficulty of concurrent development of a 5 and 6 branch as you guys are still fixing bugs and I'd have to merge those back into the 6.x branch. Depending on how much you have to do, and how brutal the changes are, this could either be trivial (though tedious) or severe.
From the looks of cvs.drupal you guys do one commit per release?
I know this might be a stretch, but- if you released a beta in the next few weeks, and then started committing all your daily changes to CVS, I could merge them into the 6.x branch as we go?
The last thing I want to do is do this privately.
How far away from a beta are you?
our postgres site will be using Drupal 6 as well, so I'm going to start in the next few weeks starting on getting drupal 6 to work.
I'm looking at the ahah framework right now, and this could be quite useful for our order admin as well as the checkout. A lot of jQuery has been re-written and should help fix some of the current JS pitfalls in ubercart.
I've been talking to the lullabot folks, as well as some of the classmates here in LA, and there are quite a few things that will need to be done in order to make ubercart D6 compatible.
First, I suggest we probably put this in the issue tracker. I have a stock D6 cvs download that I'm working from, and I'll start working on ubercart next week.
Secondly .. ANYONE who wants to work on this project needs to first study and understand the following:
Converting 5.x modules to 6.x:
http://drupal.org/node/114774
Third: check dependancies:
Workflow-ng- Tables API
- Token (dev snapshot works)
- uBrowser
of these that aren't upgraded, suggest working on updating these first. Or finding D6 replacements
Fourth: find any fundamental code changes in ubercart, caused by drupal6
example: all the postgres install stuff, the install process in D6 eliminates this problem. Note: still need to make sure our queries are Postgres compatible..
D6 actions -- some of the folks here I've talked to hate workflow-ng with a passion. I think with the upgrade to 6 we should nip workflow-ng in the bud and use actions.
http://drupal.org/node/172152 --> actions
Fifth: with all these changes, obviously ubercart will become branched.. which then means back-porting changes, etc... The only way a D6 conversion will work is if we have people working in both branches to keep them synced, and ugh this won't be easy to do.
My company has pretty much been sold on the awesomeness of D6, and don't like the thought of building a site that works for D5 then having to upgrade again to get new features... It sounds like a few others are in this boat, so I think we can do it!
Thanks for making up the checklist. For starters, let me just inject something at the top of the list and then interact with it.
I think the absolute first thing to happen should be the 1.0 release. Porting beta code to D6 that we'll have to then fix in two places just doesn't make sense. Also, spending our development time now on updating to D6 means the 1.0 would get delayed even further. One of the questions from "The Joel Test" that I think bites a lot of module developers is, "Do you fix bugs before writing new code?" I'm not saying UC should be perfect (because I know it's pock marks all too well), but we should definitely solve known bugs first.
First, I suggest we probably put this in the issue tracker. I have a stock D6 cvs download that I'm working from, and I'll start working on ubercart next week.
That's fine with me... are you thinking just tracking all the updates in one mondo patch? That'll get ridiculous pretty quick I suppose. Maybe starting off w/ just the 4 core modules will be the way to do it.
Secondly .. ANYONE who wants to work on this project needs to first study and understand the following:
Converting 5.x modules to 6.x:
http://drupal.org/node/114774
I've done this off and on and worked on a little budget module for my wife and I in D6, and what I've seen makes me think there are going to have to be some over-arching design goals for how to use Ubercart w/ the new menu system especially. Particularly I'm thinking the use of specifying the "file" attribute for menu paths and also using this trick I picked up from chx in appropriate places to trim down our menu sizes.
Third: check dependancies:
Workflow-ng- Tables API
- Token (dev snapshot works)
- uBrowser
of these that aren't upgraded, suggest working on updating these first. Or finding D6 replacements
This'll be a biggie, b/c we do rely on several other modules for core image support. That's a must have feature for Ubercart, so we will be a little at their mercy.
Fourth: find any fundamental code changes in ubercart, caused by drupal6
example: all the postgres install stuff, the install process in D6 eliminates this problem. Note: still need to make sure our queries are Postgres compatible..
Agreed. New menu system, updated form system, new schema API... Ubercart is a set of pages, forms, and install files. Essentially everything we've done will be affected. 
D6 actions -- some of the folks here I've talked to hate workflow-ng with a passion. I think with the upgrade to 6 we should nip workflow-ng in the bud and use actions.
http://drupal.org/node/172152 --> actions
I still disagree with this primarily because there are no conditions. The beauty of Workflow-ng is that it has a UI (even if it's a little rough) that allows folks to attach actions to events based on conditions. We simply have to have them for Ubercart. If the core actions module supports this, sign me up. Otherwise we'll have to look into porting Workflow-ng or trimming it down and adapting it for core Ubercart. Right now, Workflow-ng handles conditional taxes, shipping, order updates, etc. And we hope to outsource notifications to it when we update and drop the uc_notify.module altogether. Such a core module can't just be abandoned without almost a 1:1 alternative.
Fifth: with all these changes, obviously ubercart will become branched.. which then means back-porting changes, etc... The only way a D6 conversion will work is if we have people working in both branches to keep them synced, and ugh this won't be easy to do.
Yeah, I'm not too sold on the idea of maintaining the 5.x version indefinitely. At least the core team isn't planning on spending a lot of time maintaining a branch for what we'll see as an inferior version of Drupal. It just makes sense for the software to move on with the platform it's built on. I'm not saying we'll abandon it, and we'll definitely port back major bug fixes... but new features can be counted out without an easy drop in patch and a good explanation for inclusion. 
Will be interested to hear your response on these things.
Guys,
My idea may sound aggressive at first, but here is what I think. By the time you release final 1.0 version for D5, alot of people experimenting now with D6 will not be able to participate and test Ubercart. This is missed opportunity to stabilize the software with the feedback coming. I think the people running the software on D5, has pretty much got what they need and you will have hard time hearing feedback from them. I think the best next step now is get the software up and running ASAP on D6. Committing changes back to the 5.x branch is not so hard as people usually think.
Regards,
Ivan
Spent some time this last week and looked over all of the modules for Drupal 5. What was interesting is that 99.5% have not yet been updated to Drupal 6.
IMO it will take months and in some cases a year before all modules are fully compatible with Drupal 6. Some will never be updated and will just go away for lack of support, etc. Noticed that Drupal 6.1 is now out......
Perhaps someone else has a better insight on this scenario.
Jim
I think you're right... They're talking about releasing drupal7 in one year. If I look around now, most active 5.x modules are left "as is". Some are preparing for 6.x, but most of them still have a lot to do! Views2 might make it worth to switch to d6, but until then... I know we won't be making any 6.x sites.
Drupal 5 contrib modules started workin en-masse about 3-4 months after its release. There are still some biggies that need to be done for D56: Views2, CCK, etc.
Right now I'm just hoping ubercart 1.0 can be released so I don't need to backport anything, or branch my own ubercart v6 code. We have a fairly strict time line to get ubercart in D6 by the end of April... time is ticking!
Here's a list of the newest releases since the last list was made.
Seems like things are moving faster than some would have expected.
- token 6.x-1.10 by Eaton - February 22, 2008 http://drupal.org/node/106016/release
- tapir 5.x-1.5 by rszrama - February 11, 2008 http://drupal.org/node/97996/release
- ubrowser 5.x-1.3 by rszrama - February 11, 2008 http://drupal.org/node/117177/release
- workflow_ng 5.x-2.0-beta1 by fago - February 10, 2008 http://drupal.org/node/156279/release
- imagefield 5.x-2.0-rc6 by dopry - February 21, 2008 http://drupal.org/project/imagefield
- google_analytics 6.x-1.0 by hass - February 15, 2008 http://drupal.org/project/google_analytics
Well, I'm rszrama, and I haven't touched the Drupal 6 versions of TAPIr or uBrowser yet. I think Views and CCK are much bigger and more essential to site's going with Drupal 6 over these more lightweight modules. Also, we may have to find an alternate solution to Workflow-ng if it doesn't get preserved and updated to Drupal 6. Still not sure what's going to happen there.
Workflow-ng will be ported to 6.x. It will receive some improvements for 6.x and rename to "Rules Engine. I hope to have it done until the end of the march.
If you have some suggestions or features you miss, now would be the best time to tell me.
hahhha fago@drupal.org: i was just about to post how workflow-ng will be integrated into drupal 6 -- I saw the rules engine project page, but I'm not sure how complete it is?
It'd be good to hear that it's feature complete by march, since this is a major part of ubercart now. Perhaps if we're working on ubercart while you're working on the rules engine, we can identify some of the issues with workflow-ng and hope that they can be fixed in D6.
So now that CCK and Views are ready to rock Drupal 6, that means that the following have yet to be upgraded: Workflow_ng to Rules Engine, Tapir, uBrowser, ImageField.
I guess half of those are Ryans.. Hey rszrama, how are you doing? Can we help?
In my experience with Drupal over the past few years, it's best to be one major version back, at least until the new version has been out 4-6 months. This gives everyone time to catch up and get stable. I wouldn't even consider building a complex, 3rd party module dependant, site on Drupal 6.1 at this point. Drupal 6 has only been officially out for a month! You will find too many modules aren't ported or stable. With PCI requirements and other concerns, shops need to be stable and secure. Bleeding edge is not a good thing for shop sites. Also, many existing Drupal site developers wait a bit to upgrade all of their sites -- for stability reasons, and it's just plain tiring and not something that you do lightly or quickly.
I think it would be a very good idea to focus all efforts on getting Ubercart 1.0 out the door. The port to DP6 will be much easier as well if taken from stable code. I'm not suggesting waiting until every bug is fixed -- that never happens anyway.
I think it would be a very good idea to focus all efforts on getting Ubercart 1.0 out the door. The port to DP6 will be much easier as well if taken from stable code. I'm not suggesting waiting until every bug is fixed -- that never happens anyway.
Ahh, my sentiments exactly. Also, very keen to point out the security and stability requirements shops will have. A closer examination of CCK/Views will also show that neither are out of alpha yet, and it will take longer for Views as it's combining the D6 update with a version change.
Assuming no major bugs, I'll be putting up a release candidate soon. Once we get the 1.0 out the door, the effort to move to D6 will get under way.
Regarding my modules you listed, I'm actually going to try and leave behind uBrowser and TAPIr, but I haven't fully planned that out yet.
I'm building a Drupal 6 site and I'd love to use Ubercart. I understand that there is a fair amount of work to get it ported. Given that Ubercart 1.0 is pretty much done (I'm expecting a release any day now , how long do you think a D6 port will take?
Is there any way I can help? I'm not familiar with Ubercart internals, but I have upgraded a few smaller modules to D6, so I know the basics required.
Thanks,
Nick
Gonna bookmark your post for future reference. Ideally, I'll put out RC 5 this week, and if it stands on its own two feet for a week, I'll put up the 1.0 release. After that, we'll be diving into the D6 update. Some of the work has already been done, but there's a lot left to do. I'll probably create a group for it at http://support.ubercart.org when the time comes so we can coordinate the activity.
Since workflow_ng isn't being updated to rules engine very fast, I've started getting workflow_ng converted for drupal 6. This will help us get ubercart converted to drupal6 even quicker.
Some discussion at drupalcon indicated that D6 version of ubercart 1.x shouldn't have any new features, just be the d6 version. Because of this, its important to have the same dependancies as well.
I've converted all of ubercart to d6 to the point that coder.module likes it. However, this weekend at drupalcamp PDX I hope to talk some other drupal 'ninjas' about peer-reviewing d6 code. I'm about 99% certain that the changes I made won't work because of some conversion misunderstandings. However, I'm keeping RCs up to date with my D6 conversion, and once 1.0 is out I'll release this code so we can have a quick conversion!
If you have further questions, find me on #drupal-ubercart on irc.freenode.net
~Jakob
Hey Jakob, my goal is to actually get rid of the dependencies... if we go through all the trouble of porting them to D6 and debugging them, we may as well remove them altogether and accommodate the changes in the source. I suppose that's technically creating new features, but I think it's better in the long run. I've already devised a replacement for TAPIr, and I'm pretty sure we can just remove uBrowser from core with almost no headache. This has mostly been in the spare moments I get between projects w/ Lyle here in the office, but soon we should start coordinating through http://support.ubercart.org/project/32.
Perhaps removing tapir and uBrowser would be a good thing for D6, I'm talking more about workflow_ng (and subsequently the token module) -- its going to be a while before the rules engine is working properly, and when this module is released, its going to require major code changes. I however, don't believe we should be doing any dependency changes no matter how small, for 1.0. That should be done on the 2.0 branch. This brings up the question of, "do we want ubercart-1.0 for D6 released?" I'd say yes. Why? because this can be done within a month.
In the meanwhile, there is a large demand for D6 support, so my belief is to get the 5.x-1.0 release ported to D6 quickly, which should limit our issues to only API changes made in D6. This will make bug fixing a lot easier to tackle. Besides, I've already done all the grunt conversion work... now we just need to figure out the harder parts that need converting (forms api in particular).
I've already rebuilt tapir, and uBrowser in D6 and they appear to be working.
http://www.ubercart.org/forum/development/3995/tapir_15_drupal_6
http://www.ubercart.org/forum/development/3998/ubrowser_13_drupal_6
I'm currently working on workflow_ng, which I got 'converted' today, but it is not working. I'm soliciting help for this, but no one has come forward yet.
Once these modules all function, I think we'll see a quick conversion path to ubercart working on 6.x-1.0. Thanks for putting up the support.ubercart.org page, I signed up and I'll submit code, if I can as soon as I can.
I don't see why we shouldn't change Ubercart's dependence on other modules during the 5 to 6 port. After all, Drupal itself is a dependency.
Porting extra code to Drupal 6 for Ubercart's use means that we take on the responsibility to maintain it. Taking on this responsibility for TAPIr, uBrowser, and Workflow-ng is not something we want to do. Doing away with the limitations they impose on the code will make the work done on the 2.0 branch easier in the long run.
@lyle and ryan: I totally agree that eliminating dependencies is a good and needed thing. However, I disagree about doing it for the 1.0 release on D6.
It takes time to re-write uc_core modules to eliminate these dependencies. They also require contribs to eliminate these dependencies. The more changes you make to the 6.x-1.0 release, the less likely it'll work without new bugs popping up, causing it to not be released within a timely fashion.
With the dependencies either working on D6 now, or in beta testing, I don't see a problem with making these dependencies work. It'll take a lot less time to make these modules work in D6 than it will be to rebuild new internal modules to take their place. I'm hoping to get workflow_ng finished tonight so I can start testing ubercart on drupal 6.
We need to jump on getting a D6 stable module. If you guys think you can re-write, test, and debug all the modifications needed to make ubercart not dependent on workflow_ng, tapir, and uBrowser within a month or two after 1.0 comes out, great. I just don't see that happening. With the large amount of users requesting D6 support in ubercart, we need to be converting modules not re-writing them.
I'm not sure I understand everything that is going on here, but would this be considered forking the project? I guess that is a natural part of open source...
If the japerry d6 Ubercart is going to be significantly different in code base and concept than the ubercart.org d6 Ubercart, though, I wouldn't mind seeing it called something different. My main concern is confusion amongst users, within support forum topics, in IRC chat, and on a admin's update.php page over what exactly is going on.
all I'm suggesting is a 6.x-1.0 version of ubercart, nothing more. From what I'm hearing though is that I'll have to fork my own version of ubercart to work with 1.0 dependencies until the Ryan and Lyle come up with their own D6 version, which should probably be named 6.x-2.0-alpha1. When this 'official' release comes out, my version will no longer be needed.
Also, my version would be fully compatible with all contrib modules that are version 1.0 compatible, given that they can be converted to D6 as well.
Since 95%+ of the code will be the same, I'm guessing/hoping that my code will be a good basis in which the uberteam can make a good D6 release -- this should gain them about 2-3 weeks of dev time in grunt converting of code.
That all said, if anyone has dev experience, and especially D6 dev experience or wants to learn, I'd love some help. The grunt conversion process is done (using coder.module) but there are a lot of API changes that need to be looked at, especially regarding the new forms API. Send me a PM if you're interested.
The main problem isn't that you're trying to get us to D6. The issue is really that you're putting the cart before the horse and trying to force a conversion by yourself. It's one thing to head up a community effort, it's another thing to bypass the rest of Ubercart development to force a D6 conversion b/c "so many people are requesting it." (I'll point out that many people request a lot of things that we decide it's not in the best interests of the project to do.)
I have no problem with you doing what you're doing, but I'm not going to get into the hole of releasing a D6 version of a module like Workflow-ng and have to spend time maintaining that that I could rather spend working on Ubercart. I'm glad you have the time and energy, and I don't want you to feel like your efforts are wasted, it's just a little counter-productive to argue these points while Ubercart 1.0 for D5 isn't even out yet. That initial release continues to be our goal, but rest assured we are making preparations for a full scale D6 conversion as soon as it happens.
You know... we're dependent on CCK for image support, so if you're really anxious to do some grunt work right now, helping them, image field, and image cache get up to D6 would be time well spent.
So what's the official vision for branching UC? Right now the Bazaar version is a moving target, and contains the latest and greatest. While everyone is off testing the RC, the Bazaar version now has many changes and fixes which are not being subject to general testing yet - inevitably, the next RC is going to reveal some new bugs that have been added in all these changes since the last RC. At some point the RC needs to be branched off and frozen so it can be tested and debugged by the general populace while progress is still being made separately on the HEAD version. In other words, I'm arguing for a fork NOW so that 1.0 can be as stable and bug free as possible.
I don't understand what happens after 1.0 - does the Bazaar version turn into a D6 port project, is the D6 port branched off of the 1.0 release, or is the D6 version going to emerge full-blown in some other repository? Where do new features get added in, the D5 version or the D6 version or both? How long are the two versions going to track each other? What about contributed modules?
I don't feel like the Bazaar version has been a moving target lately. Ever since we had an RC version, we've had a kind of unofficial code freeze. Or at least a code slushie. Very few features have been added while all the rest of the changes have been bug fixes and typo corrections. We will have an RC5 because Ryan wants to change the default credit card settings, and that needs more testing than fixing a typo. After that, if nothing tragic happens, we should release Ubercart 5.x-1.0.
Once that happens I'll open up the 6.x-1.0 branch. It'll start out as a copy of the D5 code and the porting work will happen there. New features won't be added in until the 6.x-1.0 version is ready and posted to drupal.org. During that time, only gross bugs that aren't taken care of by the D6 port will transfered between the two branches.
As for contributed modules, it's their maintainer's responsibility to keep up with the code. At the very least, they should say what version they are compatible with, starting with 5.x-1.0. That version of Ubercart will be available at drupal.org at least until Drupal 7 rolls out, and probably longer than that.
Hi Lyle,
I'm not saying it as a criticism, just a statement that there are changes being made almost every day the Bazaar version, and each change potentially breaks something. And since most people download the RC and stick with that, only the RC gets a workout - the Bazaar updates don't really get any testing until the next RC. That's what I mean by a moving target - a bunch of changes show up in each RC, people install it and immediately find one or two small bugs, then a bunch of new changes are made (not just fixing the few small bugs) before the next RC. The need for so many RCs is due to the *process* of development rather than the quality of the coding.
There's always something that would be nice to add or fix in any piece of software. I don't want to freeze development - that could go on in the Bazaar HEAD while RC is branched. If *only* bug fixes were added to the RC branch then RC would approach stability quicker. And I *do* want 1.0 to be solid, because we're going to be stuck with it for a while.
Ubercart isnt e-commerce.module. Ubercart sticks way out above a lot of drupal modules in terms of usability and functionality. You know why? Because some good developers and projectleads made a decent plan, and sticked to it. They did (and do) listen to community, but keep the red line of the initial plan. Never implement things because some people shout that you should.
I suggest that they continue doing just that.
I'm 100% behind the Uber devs in progressing to D6, any way they are PLANNING to do so.
Thumbs up guys!
I don't see why we shouldn't change Ubercart's dependence on other modules during the 5 to 6 port. After all, Drupal itself is a dependency.
Porting extra code to Drupal 6 for Ubercart's use means that we take on the responsibility to maintain it. Taking on this responsibility for TAPIr, uBrowser, and Workflow-ng is not something we want to do. Doing away with the limitations they impose on the code will make the work done on the 2.0 branch easier in the long run.
I think this depends on whether or not the Drupal 6 version is to be 2.0 or 1.0. If Ubercart 1.0 for Drupal 5 is to be converted to Ubercart 1.0 for Drupal 6, then the code should remain as close to the Drupal 5 version as can be, meaning keeping with all the dependencies. By not keeping with the dependencies than I feel the Drupal 6 version should in fact be Ubercart 2.0 as it would contain New features. One might argue that moving features provided in a different module into Ubercart are not New features since they are basically the same just Ubercart working the magic instead of them, but my reply would be that it is a New feature for 'Ubercart' itself and thus would need the version 2.0 stamp. TAPIr, uBrowser, and Workflow-ng should be converted to Drupal 6 for Ubercart, otherwise the changes to Ubercart 1.0 are too drastic to call it version 1.0 even if it is for Drupal 6.
By implementing features provided by another module inside of Ubercart opens the door to making those features better and adding features to those features. I feel unless the Drupal 6 version is a 2.0 release then no changes should be made to Ubercart other than converting it from Drupal 5 to 6.
I think I repeated myself on some points, but it's really late and maybe the different wordings will help get the point across. I hope I'm not alone in my thinking.
So now, it's really just an issue of semantics. On the one hand, Ubercart will accomplish the same tasks as it did before with only the changes necessary because of Drupal 6. On the other hand, some of those changes involve entirely new code. Almost makes me want to call it 1.5.
How's that for ambivalence?
So now, it's really just an issue of semantics. On the one hand, Ubercart will accomplish the same tasks as it did before with only the changes necessary because of Drupal 6. On the other hand, some of those changes involve entirely new code. Almost makes me want to call it 1.5.
How's that for ambivalence?
No its not about semantics.
*Sigh* you guys just don't get it... The fact that you guys cannot recognize that putting in **new** code with **new** function calls and **new** fundamental ways to perform tasks isn't a feature change is beyond me. Ubercart isn't some petty little php script written in a basement for a few users, ITS A MAJOR SOFTWARE PACKAGE THAT SHOULD FOLLOW SOFTWARE DESIGN STANDARDS!
Lets take workflow-ng as an example: Three potential options...
1) you convert workflow-ng to work in 6 so all the modules in ubercart (and any contribs mind you) don't have to change how they do stuff, or
2) you create a new 'uc_workflow' module (which is what the wombats wanna do) that will be nothing like workflow-ng in the end, because I know how you guys like to stick in little improvements without any planning... this will break *everything* that uses workflow-ng, including modules that you might not know about that end-devels have created to work on their systems.
3) Perform option 1 right now in the interim for 6.x-1.x-ubercart, and for 6.x-2.0 work with the drupal community to create a module that adds conditionals to actions and triggers in D6 core. This is the 'rules_engine' Its not complete, and needs help. Lets help fago get this done! Don't go off and fork your own code! it splits the community, causes extra work, and hurts *everyone* -- this will let ubercart get to D6 quickly, and once thats done you can do new stuff to the 2.0 release.
I've been advocating option 3 ever since drupalcon, and have done some work to bring code upto speed. Its great to hear some others are working on this. I have my sandbox here, but its based on RC4 code and is very incomplete -- however a lot of the tedious stuff, like install and info files, are all done and just need to be matched up with 1.0: http://fcdnet.org/japerry/d6-sandbox-UC_RC4.tar.gz
But in the end, I know that the wombats will just go ahead and do their own thing--release a 1.5/2.0/alpha/D6-ubercart-that-will-break-everything-that-works-1.x. If you look earlier at this thread, irc convos, etc, you can see that they don't really care to follow the advice of anyone else, so there is really no point in trying anymore.
I'd like to add a thought about stability. Remember that many shops consciously stay a revision behind on Drupal releases (at least for 6 months). This is because of the myriad of necessary contrib modules (like views etc.) that can take a while to get ported and become stable. And also, it usually takes Drupal a month or two to get to a truly stable release (ala 6.2). Stability is key for existing shops, especially with requirements like PCI and third party integration with things like PayPal etc.
So, I'd like to suggest that porting without radical changes is usually the best approach. It reduces the "moving target" effect of testing things that are broken, things that worked on a previous version and are broken in the newer Drupal version. Keeping adjacent releases (5.x 1.0, 6.x, 1.0) in sync will make testing and maintaining stability much easier. And if bugs appear in new versions, you can look to the differences between Drupal versions and not worry about changes from a radically reworked code base. This issue will surface again when you abandon Drupal 5.x and are porting 6.x to 7.x. If it's good enough to be 1.0 on 5.x, a direct port to 6.x should be a good 1.0 as well.
I feel that a major reworking should be done as a Uber 2.0 release, and probably for Drupal 6 or 7 only. I'm wildly guessing that porting the existing structure to Drupal 6 will not take as long as doing a rework and port. This will also allow you to get a 6.x version out the door and take your time with a 2.0 rework -- which will always take much longer than expected. The automatic doubling rule usually applies.
Ok, not trying to preach, just my two cents from running some rather large projects over the years and trying to keep up with moving targets. Whatever the outcome, I truly appreciate your efforts and hope to start contributing code/patches to the 6.x effort.
Ok, not trying to preach, just my two cents from running some rather large projects over the years and trying to keep up with moving targets. Whatever the outcome, I truly appreciate your efforts and hope to start contributing code/patches to the 6.x effort.
Certainly didn't feel "preached at", and thanks for sharing your experience. We have a (noticeable) lack of experience in the area, so we're happy to keep learning.
Based on your comments and some others, here are my thoughts... I'd love to get some feedback on whether or not I'm totally off base.
- TR raised the issue a while back of a moving target for core late in development of the 1.0. I'd like to change this for the next release. Until now, we've basically been writing and debugging code as fast as possible just to even get to a 1.0. We have a better idea of the kinds of snafu's to watch out for and probably will be slower to dub something a beta release/release candidate in the future.
- I do feel the need to change dependencies for practical and code-related reasons. The practical reasons are that Ubercart continues to get criticized for its dependencies, and being dependent on a separate, large module package restricts the development of your own (in our case, Ubercart).
Regarding the former, modules like TAPIr and uBrowser were released separately b/c I thought (erroneously) that they might be useful in other contexts. I've really never heard from anyone using those modules who does not use Ubercart. This doesn't mean those people don't exist, but it does mean their sites will continue to work for Drupal 5 and if they want to port those modules to Drupal 6, I'll happily hand over maintainership. These modules didn't even turn out to be highly usable in Ubercart. There's even an option that lets you turn the uBrowser off completely in core, and TAPIr wasn't as extensible as hoped. I dub these two modules my early experience modules.
Regarding the latter, right now Ubercart is compatible with the 1.x version of Workflow-ng. It will mostly work with the 2.x, but some internal links will be off. This happened too late in the game for Uber 1.0 for me to feel confident doing lots of testing and updating our code to work on the Workflow-ng 2.x branch. Now, as japerry pointed out, Workflow-ng will be coming into Drupal 6 as the Rules module. Anyone w/ custom Workflow-ng code will have to change it anyways, as with many other things in their modules. Proposing that we convert Workflow-ng to Drupal 6 and maintain it ourselves is short-sighted, I believe. The module developer himself isn't doing this, and we've been around inside the current code. It's dependent on the Drupal 5 Forms API, a dependency which has received its own batch of updates in Drupal 6. We'd have to spend a lot of our (limited) development time doing and maintaining the update... or, as was recommended to me by another dev and a core developer at Drupalcon Boston, we can just integrate our own trigger/action engine that handles conditions and integrates better into Ubercart. We could, as was suggested, help out instead with Rules and make sure folks can port their code from Workflow-ng to Rules... but then where will we be when it's time to update to Drupal 7?
Also, fwiw, I wrote a fully documented predicate parsing engine in a few hours (modified by Lyle to handle nested conditions) with just a few hundred lines of code (compare to the amount of code in Workflow-ng based on the Forms API...). It worked great in testing and has a hook syntax very similar to Workflow-ng so that modules updating to the Drupal 6 Ubercart won't be stuck with major rewrites. We will have an update guide much like the D5 -> D6 update guide to help with updating modules. I don't think moving ahead here will mean a slower update time, and I'm pretty convinced atm that polishing this off w/ a UI that can be used in context for taxes, shipping, etc. will be quicker than tying ourselves up in Workflow-ng.
- I don't want to make a whole lot of other changes when migrating to Drupal 6. We've seen with Views how much longer it makes the whole updating process. It sounds to me that changing the dependencies will be a bigger deal than we thought, so I'd like to make the following proposal...
In moving to Drupal 6, we can go ahead and call it Ubercart 2.0. This version will be a full port to Drupal 6 along with the dependency changes and any bug fixes that turn up between now and then. We'll still be releasing this as fast as humanly possible, and we won't change other core features until this version is done or unless (as was the case w/ the CC module, even if I was slow to get to the fix) a security problem is pointed out that needs to be resolved.
After this, I'd love to move on to tidy up our internals, revisit internationalization, and get on to some actual innovation.
Does this sound reasonable? Or given my explanation of the Workflow-ng choice, would it still be reasonable to not call this a 2.x version?
Hey Ryan, for what it's worth, I think your approach makes sense and your reasons for changing some dependencies are sound as well. Good post, thanks for the detail! Oh, and happy 4th.
Is there a way to create a tasklist for the Drupal 6 migration? That way you and your core team can work on the really nasty dependency changing stuff and maybe put out some stuff for the rest of us to work on? Happy to contribute code if needed or port a sub-module.
Thanks for the comments, guys. Where we stand right now is 20/32 modules converted with another in progress and one that will be deprecated (notifications). The D6 version is running and very ready for testing. I have a dev server up at http://d6.bywombats.com if you just wanna take a peak.
For more information, join the Drupal 6 support group and check out the migration status. That post has info on where to direct your testing and review efforts. We haven't touched some of the modules that need to be converted. You can use the coder module to make the job easier, and the modules that have already been done can serve as templates for how to do the conversions. Hopefully we'll be near complete conversion by the Ubercamp and then hack out what's left that weekend. I'd love to get the 2.x out for D6 before Drupalcon Szeged.
The only remaining dependency issue is to get a UI around the conditional actions... I'll be shooting for something akin to the Views 1.x UI for setting up conditions if possible.
Hi I'm totally new here. I see your lists is long...I wish I new how to build modules so that i can ofer help. One day. Is it too late to request a feature? Probably. Ubercart appear in my humble opinion to be way more adanced tha the eccomerce module through drupal. I was hoping there would be a way to implement userpoints with ubercart instead of having to use the eccomerce module. Thanks, Alvina.
This is a really long thread, but I do want to weigh in as a user of ubercart who has had my store up and running for 7 months.
I do not care about a smooth or perfect upgrade path from drupal 5 to drupal 6, and I do not care about perfecting UC v1 for drupal 5 before moving on to a Drupal 6 version.
I would much rather have a UC version for D6 so that I can play with all the new toys at once.
I agree with nekobul. People who have invested time and effort into 5 have what they need. And I do not think you need to take any new features you build in 6 and back port them... I have not touched my site in 7 months. I am going to have to do so much upgrading on so many modules, I will probably just start fresh...and it would be great to do that with D6.
At the end of the day, if I want a new feature, I would much rather have you tell me I need to upgrade, than to have you tell me I need to downgrade.
I knew I was on the bleeding edge when I built my site using UC (as opposed to using a licensed product that was at a release 2.x). I think most users feel that way, and you might feel "artifically" bound to keeping on the D5 track because I know you are good guys trying to do the right thing and don't want to leave anyone hanging...but as for me, bring on the D6 version, and I will do whatever upgrade/rebuild/start from scratch/ process you suggest.
And one more insight...I am already getting pressure from my hosting company to upgrade to D6, as they see D5 as a security risk. If that happens, I have to move hosting companies or start all over with another shopping cart if there is no UC for D6!!! And I don't want to do that!
Not yet, though it can be checked out from our Bzr repo as mentioned above or from Drupal CVS as the DRUPAL-6--2 branch. Once Drupal packages it, you should be able to find it in this release: http://drupal.org/node/280820
I just tried installing the D6 version and now the Modules page comes up blank every time.
After I go in and manually drop the uc_* tables in MySQL and remove the ubercart directory the page comes back up just fine.
Is there a way to totally back out any initialization changes that happened during the module install?
What parts of the modules are enabled on the test D6 website?
Thanks!
We really, really want to get Übercart 5.x-1.0 up and running first. Once that happens we plan to put (nearly) all of our efforts into Ü 6.x-1.0. There's quite a list of things that will need to be changed and improved to make Übercart compatible with Drupal 6, but we still want to be compatible with Drupal 5. Drupal 5 will be supported up until Drupal 7 gets released, so plenty of people will still want to use it for a while. Übercart needs to be there for them.
Since Drupal 6 and Ãœbercart 1.0 will be coming out around the same time, all the new features that we make for Ãœbercart 2.0 will be for Drupal 6 only. D6 looks to be much better from a developer's standpoint, so we won't want to take a step backwards and write new things for D5. Major bugfix releases will probably still be made for the 5.x version, but only if they are severe enough. I can't say at all how we'll decide that until the time comes.
As for what needs to be changed, just the very basic hooks like menus, database schemas, and forms.
You know, 90% of a module's code. This is a checklist of all the things that are updated between 5 and 6. Ryan, Shawn, and I are going to go through each module and compare it to the checklist. I'm thinking it'll be fairly easy, but tedious. I don't know if there are any tools other than the handbook pages, but I'm the kind of guy who'd want to do it myself anyway. 