Creating a beta release of the 6.x-2.x branch (and beyond)

Fair warning: I'm abusing this issue into a bit of a roadmap discussion.

After perusing the queue for a bit, I think there is one beta-blocker:
#1015980: Fatal error: Call to undefined function salesforce_api_id_load() on line 62
-- this should be a relatively a quick fix once we identify an optimal approach

Other than that I think we are ready for a beta.

Next, we should definitely address #1034030: Sync new handbook page with README.txt & re-point documentation link on project page before thinking about a full release.

Also, there are a few outstanding issues on the project page that seemed to have had some traction at the last Drupalcon.
#785268: Two way sync rules on the field level Two way sync rules on the field level
-- For me this would be a really really useful feature, and the effort/benefit ratio is low enough that I think this could get into a full release.

#785286: Provide ability to create one-to-many fieldmaps One-to-many fieldmaps
-- This would also be a really really useful feature, but unless someone else can come up with an elegant approach, I think the effort/benefit ratio will be significantly higher compared to 785268 -- maybe punt to 2.1 or later

#785304: Security Audit Security Audit
-- I'm not really even sure about how to approach this, so I'll have to suggest that we punt on this one

#785274: Implement optional queuing system for exports Implement optional queuing system for exports
-- sf_queue is already in DEV, so this issue should probably be closed or renamed

Thoughts?

I think we should also get kostajh's #477182: Encrypt API password and token in prior to a beta, as well as the one you mentioned. Then the beta can be fairly quick, probably just #1034030: Sync new handbook page with README.txt & re-point documentation link on project page.

I also think that it's time for a beta.

The other issues you mentioned, Aaron, don't seem to be too close to fruition, so they could be 2.1 (or later, depending on how they go).

The more significant refactoring of #1018674: Implement entity schema for 6.x-2.x branch & #990700: Support the new REST API, etc., actually sounds like a 3.x branch to me, simply because it would probably take a while to be stable, and it would possibly not be backwards-compatible. I'd like to have the 2.x stable branch stay up on the project page while that work was going on, so that I could say that my Ubercart Salesforce Integration module was compatible with the current stable 6.x version of the Salesforce Suite.

I think we should shoot to have a 2.0 stable by Drupalcon Chicago, so we can discuss what comes next more at the conference (in a BoF, etc.).

It might be cool to get #931168: "entity is deleted" error if changes exported to Salesforce after the matching record is deleted in before a full release, also, just because that is a somewhat confusing and tricky error. (Happens sometimes in conjunction with Ubercart/Salesforce).

Cross referencing D7 port discussion: #990660: D7 port

Looks to me that of the bugs mentioned earlier on when this discussion started, only #931168: "entity is deleted" error if changes exported to Salesforce after the matching record is deleted is still open. Are there any others that are blocking a beta release?

In addition to #931168, IMO these are low-hanging fruit, and should be addressed before a beta:

• #1041306: Bug when installing sf_notifications module
• #1027566: sf_user_skip_export variable not being unset properly in sf_user_import()
• #1034030: Sync new handbook page with README.txt & re-point documentation link on project page
• #1042296: Link- vs. object-based synch behavior

If a couple more people can put eyeballs on them, I would feel a little better about getting them committed.

I'll try to take care of #1034030: Sync new handbook page with README.txt & re-point documentation link on project page myself this weekend. Was going to do it last weekend, but client work took precedence.

re #10: that seems most reasonable to me.
I think we'll have to punt on a more robust solution for #1058870: user_save fails in sf_user_import().

So, we're down to (or is it up to?) 4 beta blockers:

• #1042272: Pre and post import hooks
• #1042296: Link- vs. object-based synch behavior
• #1027566: sf_user_skip_export variable not being unset properly in sf_user_import()
• #931168: "entity is deleted" error if changes exported to Salesforce after the matching record is deleted

down to one issue
#1042296: Link- vs. object-based synch behavior

As much as i had hoped to get a beta out the door before Drupalcon,
I think 1042296 is sufficiently complicated and sufficiently important to delay the release.

Still just one issue prior to beta of 6.x? Seems like a lot of activity still happening on that branch... I think something that has the 6.x-2.0 label on it would be great to get out soon, though, to drive adoption, especially with requests for 7.x becoming more frequent. I think the basic architecture of 6.x-2.x is sound, and I am willing to live with it for the lifecycle of uc_salesforce 6.x, although it will continue to require me doing some hacks.

Looks like a lot of new tickets on 6.x-2.x (some very important). Should probably postpone the beta for at least a few weeks.

Posting here to note that #1198786: _salesforce_fieldmap_access() fails to check permissions definitely needs review before a new release.

Yes, agreed.

Anyone care to make a list of the issues that are important to them prior to a 6.x-2.x beta? The biggest decision would be whether #1018674: Implement entity schema for 6.x-2.x branch makes sense to do.

I think that one might be better for a 6.x-3.x, after a 6.x-2.x stable were released. The other things that I would like to see in a theoretical 6.x-3.x would be the REST API and OAuth support. Those things will probably be implemented in 7.x eventually.

One day short of this ticket's first anniversary, and only one ticket of those listed above left open - #1042296: Link- vs. object-based synch behavior, can I get this discussion started again?

the process for fixing security issues becomes more complicated once a module's in beta

No, it doesn't. See http://drupal.org/security-advisory-policy

Security Advisories are only made for issues affecting stable releases (Y.x-Z.0 or higher) in the supported major version branches (at the time of writing Drupal 6.x and Drupal 7.x). That means no security advisories for development releases (-dev), ALPHAs, BETAs or RCs.

+1 for tagging a beta

re #1042296: Link- vs. object-based synch behavior,
I don't think we've solved this problem, but I don't think it should continue to hold up a stable release.
We have developed workarounds in the way of various hooks and alters so that contrib modules can change the behavior as necessary.
Especially for 6.x I don't think it's even worth making such a fundamental change.

Huzzah!
Thanks Kosta, thanks everyone!

That's great - thanks a lot.

(Nearly passed over this module for it's alpha tag, but glad we didn't as it's very useful.)

And a special thanks for being so responsive in the issue queue. Cheers!