[meta] 7.x Long-Term Roadmap

Thanks for taking these notes Aaron. If folks could publish their forked work in drupal.org sandboxes and post links here, that would be helpful to the rest of us in figuring out how to move forward with merging (or not) the code.

My work on a 7.x direct port is living here for the time being, http://drupal.org/sandbox/robinmonks/1096182 . I'm of the opinion that it would be ideal to make 7.x-1.x a direct port to get something working quickly -- and then perform the refactoring in 7.x-2.x.

This lets us maintain a more stable 1.x for general use while we refactor -- and also ensure a clean upgrade path from 1.x to 2.x when we're ready to start pushing those changes into the wild.

/Robin

Just a note that I'm still working on this in sandbox, http://drupal.org/sandbox/robinmonks/1096182 -- currently focusing on getting object mapping working again and would love help to make that go faster -- with just one person the cycle of port, test, debug, test, research, test, port next feature -- it goes rather slowly.

/Robin

@Robin: I think this is a good plan - better to have something stable for people using 7.x now than to rebuild the system from scratch, essentially, which is what it seems would be necessary for the more ambitious proposals to work.

Since Robin's port was several months old, I re-ran the modules through Coder Upgrade tonight and created a new 7.x-2.x dev branch (no project node as yet, since I would like to get it working first). I think this will make collaboration easier than working in a sandbox. Also, it will make it easier to track the progress on commits, and the forward/backward porting of issues (once we get to that point).

My goals for this port are simply to have feature parity with the current 6.x-2.x, as per Robin's earlier comment (and to track new commits as they come), but to do this using entities rather than the duplication of logic which we have in 6.x in sf_node/sf_user. This will involve me merging sf_entity back into the 7.x-2.x branch shortly, and then combining anything specific to sf_node and sf_user into it, as well as changing the schema of the module accordingly (as per the current 7.x-1.x).

My two main questions at this point are:

1) What should we do about the current 7.x-1.x issues in the queue? I think that branch is essentially a "dead end" at this point (I certainly won't be working on it further), yet people are trying to use it now. It will be at least several weeks before there is a stable 7.x-2.x that we can recommend.
2) What about Jackson River and the other groups who expressed interest in a fuller refactoring of the module for 7.x than what I plan to be doing? Should there be a 7.x-3.x as well? If so, who would take point on that, and would it be based off the 7.x-2.x once that is stable, or would it be basically from scratch?

Just started taking a look at the queue & realized that there are a lot of open 7.x-1.x issues. I think this is causing confusion, especially in light of #1197906: Release New 7.x-2.x Branch (as -dev).

Aaron & Kosta, would you mind if I were to warn people that 7.x-1.x was about to be deprecated, and then mark them as "won't fix" once there is a 7.x-2.x dev release?

Now that 7.x-2.x is out (though not ready for production use), I think the main things will be to finish converting all the modules to the new schema, write export/import handlers for all mainstream kinds of fieldable fields (at least the core ones), convert Salesforce Import and Salesforce Queue to use Drupal queue, possibly separate the fieldmapping UI into its own module, possibly do two-way sync rules on the field level.

There are issues for some of those items. I'll add the links later.

We should also contact Jackson River to see if they will a) start testing 7.x-2.x, and b) contribute any of their expertise. It would be great if we could have a common solution for 7.x moving forward, whether that is the 7.x-2.x branch or a later 7.x-3.x branch that would incorporate larger changes like switching to OAuth authentication and the REST API (rather than SOAP), or even Views 3 integration for the UI (I think some ideas were tossed around at Drupalcon regarding that, but I can't remember the details right now).

I've contacted Jackson River and some of the other people who were present at the Drupalcon BoF. Hopefully we can hear some more about what people would like to see moving forward.

I'm going to create a separate issue for my more short-term roadmap.

7.x-2.x roadmap at #1214126: [meta] 7.x-2.x Roadmap.