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.

1. 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.
2. 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.

3. 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?