- This topic has 4 replies, 2 voices, and was last updated 8 years, 10 months ago by
.
-
Posts
-
Guys. You’re killing me!
I barely get my clients’ sites updated to the latest version and I get a message that you’re breaking backwards compatibility AGAIN. How am I supposed to go back to my clients with this? (“Yeah, I’m going to need to put more developer time towards Events. Yes, I know we just did that last quarter as well.”)
For a “Pro” product you don’t make it very easy on us pros! I need a robust, stable platform on which my developers can build custom implementations. WP core does a fantastic job of this — everything is highly backwards compatible, and changes to the API are made slowly and deliberately. ECP, it seems, not so much.
Hi Marty,
Thanks for getting in touch.
Backwards compatibility is not something we take lightly — we have actually been at pains to minimize disruption and, for a great many of our users, the update experience should be seamless.
The picture is admittedly a little different for those installations where customizations have been made, but even then we’ve done our best to reduce the impact as much as possible (also, some and even the majority of customizations should continue to work as expected).
In communicating these changes as early as possible – and in making release candidates available – we hope that we’ve increased the ability for developers and designers to prepare effectively in anticipation of the final release.
I’d definitely be interested to know if you have reviewed our related blog post and have specific concerns or other feedback – and indeed if you’ve had an opportunity to take advantage of the release candidates and found them useful?
Thanks for your continued support and do let me know if there’s anything more we can do, here.
The early access to release candidates doesn’t have much utility, honestly. It’s going to take time to negotiate budget for testing, then schedule development work, then do the testing, then make any necessary changes. It doesn’t matter to me if the code is “release candidate” or the actual release– the work it creates on my end is the same.
What I’m trying to communicate is that by breaking backwards compatibility, or even just introducing the potential to break compatibility, Tribe is putting devs like me in a tough spot. If I’ve done my customizations according to the suggested approach and am using methods documented in the API, I should be able to hit “update” without worry.
Hi Marty,
Absolutely – that makes a lot of sense.
Feedback like this is extremely valuable to us and we can accept that for a number of users, developers and their clients the approach taken in this release cycle may not have been optimal.
All I can really say is this: know that we’re listening and have taken your feedback on board — the team is quite literally talking through this very subject right as I write this reply.
In case you have any further thoughts I’ll leave this topic open for your further replies.
Hi!
It’s been a while so I’m going to go ahead and close this topic.
- Need help with anything else? Go right ahead and post a new topic, one of the team will be only too happy to help
- Still need help with this issue and need to re-open it? Again, please simply create a new topic and link to this one to provide the team with some context
Thanks!
- The topic ‘3.10 – "This is a big update. "’ is closed to new replies.