function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Date for Desupport for Beta 3.3?

I have a client and they are faced with a "Heavily modify an extensive 3.3Beta Ajax solution" vs. "Rewrite it using the current versions" decision.

One factor that might contribute to the discussion is when will the old endpoint no longer be supported?  When will their current application die anyway?

Do we have any official words on that?

Thanks, Steve.
From the API doc is committed to supporting each API version for a minimum of three years from the date of first release. In order to mature and improve the quality and performance of the API, versions that are more than three years old may cease to be supported.

So, to work out the 3 year window, you'll need to know which exact api version is in use.

The API endpoint will be good for at least three years, as Simon says. The Beta Toolkit will also likely exist for as long, as long as people are using it.

However, consider this: It's not supported. It's example code. A demo of the API via AJAX. Not intended for production use. It's slower and takes longer. Not optimized for regular use. It's outdated. It's been replaced with a highly optimized version. The list goes on.

They can use it, certainly, but the translation process is virtually painless; a few minor refactorings and possibly some optimization of query loops and they're done. You only really need to look for the sforce object references and upgrade as necessary. Most of the other syntax is forwards compatible. If you have 10000 lines of code, you probably only have 1000 that need examination, and maybe 50-200 lines that need changes, and probably most of that can be handled with a Find/Replace function... maybe an hour or two for a basic upgrade. Once they're up to at least the production toolkit, they can then do incremental optimizations of the code. Use a JavaScript debugger addin to speed up the process (FireBug, anyone?), and it's painless.

Simply by upgrading to a production toolkit, they'll have the benefits of a stable API toolkit that runs fast and keeps a consistent API. The 8.0, 9.0, and 10.0 toolkits all have identical base functionality, with new features from newer APIs added in (eg. sendEmail). To upgrade an 8.0 script to a 10.0 script, change the JavaScript source file that's being referenced, and you're done. 2 characters from 1 line of code, approximately 15 seconds per script.

They'll have to eat the cost sooner or later, but by going sooner, they'll give their users the gift of faster speeds, and their developers the gift of easier upgrade paths later. And they'll save money.

It reminds me of the question I faced a while ago-- keep my old PIII (667mhz), or upgrade to a 2.4ghz machine. Yes, it was relatively expensive (the older computer was $50, the newer over 10 times that)-- I could have upgraded for a few dollars, almost literally. But, it wouldn't have been as powerful as going out and getting something decent. And, I can do much more with it than I could do with the older computer, all at once. By spending a "relatively" expensive as a base cost, it's allowed me to buy hardware modern enough that I can do modest incremental upgrades (say, $50 to $100 at a time), instead of having to go out and eventually buy that new computer anyways (which would have cost me the original incremental upgrades PLUS the cost of the new computer and it's upgrades).

Personally, I'd avoid the nickel and diming technique-- do the upgrade now and save on writing "heavily customized" code time and time again in the future. If the upgrade costs $1000, and they put off that $1000 in favor of ten $100 updates over the next year, and THEN a $1000 update... you do the math.

This has been my two cents, and does not reflect any official view or stance of or anyone else I can think of.

~ sfdcfox ~