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!
|
|
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. 
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
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.
|
|
Joined: 08/07/2007