Deprecated Log Insanity

Hi Eric,

Let me see if I can clear some things up.

Considering there was NO notice of what’s to be deprecated outside of hoping we noticed it in the dev preview (just a horrible strategy if it was one) this is incredibly irritating.

Deprecated methods were listed in the changelog in the docs download we made available during dev preview.

More, expecting your add-on developers, those who help make your product more useful to your customers, to add in boilerplate conditionals comparing EE versions throughout their code to accommodate a capricious deprecation strategy is just plain rude.

This is unfortunately how developing with a framework works. I’ve been doing iOS development for a number of years, and it’s not uncommon even for iOS devs to have to place conditionals in their code to conditionally use deprecated methods or new methods not available in older versions. Heck, we even have to do it with PHP. If a platform is to advance their codebase and get rid of cruft code, what are they to do?

Deprecations were not “capricious.” If you feel that way, please ask us why that particular method was deprecated.

It’s sort of insane guys; a select for every deprecated function? And you deprecated the JSON and Localization stuff at 2.6? 2 of the most heavily used internal functions ever and one that’s used primarily in loops? Deprecated? And you’re gonna do a SELECT for EVERY use of a deprecated function? Really? Really? Not good design there fellas…

Yes we deprecated the JSON stuff because a more reliable version is available in PHP 5.2, we want you to use the best. And yes of course Localization was deprecated, would you be comfortable using that old code to localize dates? That code was manually manipulating Unix timestamps to fake a localization and was bug-ridden and fragile. So yes, I want developers to use reliable code to localize dates.

Correct, there is a select for each deprecation call. The idea is deprecated methods shouldn’t be called anyway, so maybe that’s the intent behind the design, but yes that could probably be designed better if folks aren’t going to update their addons and run with deprecation notices in production.

Would it be possible to maybe add a setting to the logging that has to be enabled first (I can’t stress the importance of disabling that setting)? Maybe make it so it only logs on Super Admin visits (much like debug only works on SA access)?

Sure that’s an idea, we’ve been tossing around some other ideas to at least make the experience better for users when these notices pop up, we could possibly look into making sure performance doesn’t take such a hit too. I’ll bring it up.

Or, even better, please, for the love of all that’s holy, stop deprecating stuff at point releases….Seriously though; PLEASE STOP DEPRECATING THINGS.

Serious question, do you have a suggestion of how we can advance and clean up the code base, get rid of cruft, etc. without deprecating public methods? Again, it’s quite a common practice to deprecate functions, even PHP will deprecate things in a point release. As I’m sure you’re aware, a lot of EE’s core code could be better, and we’re really trying to make an effort to improve it and get rid of the years of cruft that have been around since the early days so we can replace it with something more modern, reliable and maintainable. How do we do this without pushing developers to use better APIs? Again, serious, non-rhetorical questions, I’m genuinely interested to hear how we can better tackle this problem. Keep in mind we also need to motivate developers to actually update their addons.

And please feel free to email us when problems like this come up or you have suggestions. I’d like to think we can have a discussion without sarcasm, calling us insane or rude, and the general attitude of this post. It seems the attitude here is that we do not think about our decisions (your “capricious” claim), and they cannot be changed (ranting on a public forum instead of having a calm discussion with us to resolve it). This isn’t the case. Please email us if something isn’t working out or you’d like something explained, it’s the best way to foster change for the better and perhaps lessen your feelings of helplessness. I know it’s the trend online, especially Twitter, to bang a drum loudly, complain about our code, make claims as to why we made a decision or how its stupid, but that’s not productive. It would be more productive to go directly to the ones who can change it for you and have a calm discussion about coming to a resolution.

Kevin

Hi Kevin,

Thanks for responding. I do appreciate the thoughtful replies though, to be perfectly honest, I’m taken aback by your responses and I truly, deeply truly, hope I’m wrong in how I’m interpreting this.

Deprecated methods were listed in the changelog in the docs download we made available during dev preview.

This is really only helpful if all add-on devs have access to the developer previews. Stating that you guys put up a list somewhere only a select few have access to and consider the matter handled reads reckless at best and disingenuous at worst.

It reminds me of the Hitchhikers Guide To The Galaxy:

“But Mr Dent, the plans have been available in the local planning office for the last nine months.” - “Oh yes, well as soon as I heard I went straight round to see them, yesterday afternoon. You hadn’t exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything.” - “But the plans were on display …” - “On display? I eventually had to go down to the cellar to find them.” - “That’s the display department.” - “With a flashlight.” - “Ah, well the lights had probably gone.” - “So had the stairs.” - “But look, you found the notice didn’t you?” - “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard’.”

The add-on that has the deprecated function calls that caused 200 SQL queries extra, I have come to find out, was not a part of that program. This can’t be the solution.

As to the comparison with how PHP deprecates functionality you’re missing a crucial component: they advertise the changes for months and even years before it happens. You guys give a select few developers a few weeks at best while the list of functionality to not use grows with every release. More, PHP doesn’t add in a performance penalty for using deprecated code and it certainly has a way of disabling said notices. EE doesn’t have any of those things yet adds new deprecated functionality with each point release which happens every few months. PHP is updated to a new point release every couple years. The comparison just doesn’t hold up unless you’re gonna follow their entire process instead of simply saying “they do so we do”.

This is unfortunately how developing with a framework works. I’ve been doing iOS development for a number of years, and it’s not uncommon even for iOS devs to have to place conditionals in their code to conditionally use deprecated methods or new methods not available in older versions. Heck, we even have to do it with PHP. If a platform is to advance their codebase and get rid of cruft code, what are they to do?

I disagree. Frankly, this is how developing with a framework works when the parent doesn’t take enough care with their community of developers. The good ones take care to never break the API and certainly wouldn’t add a performance penalty for not following the unknown and hidden deprecation strategy. For more information please read up on Semantic Versioning.

EE used to be such a joy to code for but with strategies like these that’s clearly becoming a thing of the past I see. Really disappointing response there man.

Yes we deprecated the JSON stuff because a more reliable version is available in PHP 5.2, we want you to use the best. And yes of course Localization was deprecated, would you be comfortable using that old code to localize dates? That code was manually manipulating Unix timestamps to fake a localization and was bug-ridden and fragile. So yes, I want developers to use reliable code to localize dates.

Changing the API and removing existing functionality isn’t the only way to do this though. Really. I too want to use the JSON methods in PHP 5.2 just like the next guy but there’s absolutely NO reason for you guys to force this on the developers to do in their code. Doesn’t it make way more sense to have that logic in the EE code and leave the API alone? For example, checking for the right JSON function in the EE_Javascript library like so:

//EE_Javascript 
public function generate_json($result = NULL, $match_array_type = FALSE)
{
 if(function_exists('json_encode')
 {
  $str = json_encode($result);
 }
 else
 {
  $str = parent::generate_json($result, $match_array_type);
 }

 return $str;
}

Done and done. No need for add-on devs to do anything, ever. They’re using EE’s API and EE’s API has them covered. No extra SQL. No performance penalty. No angry customers having their site run wild because an add-on dev somewhere in the world, who’s not even invited to the dev previews, didn’t know EE decided to change something. Change the how of your code, and not the API, and nothing should break. Plus, since EE is based on CodeIgniter, and it has to inherit the CI_Javascript class anyway, it’s not like you’re adding in extra maintenance for your team; you’re just taking issues away from your add-on community. This is a win/win. The current way is a win/lose. As a developer, which would you choose Kevin?

As it stands now, it’s sounding like a better strategy for EE add-on developers to reinvent the wheel for all our projects than rely on the EE codebase to help ease the pain. This is not how you build loyalty with your developers or make it desirable to work with and it certainly makes developing for EE a PITA but with the alternative being working code breaking randomly I don’t see another workable choice.

Correct, there is a select for each deprecation call. The idea is deprecated methods shouldn’t be called anyway, so maybe that’s the intent behind the design, but yes that could probably be designed better if folks aren’t going to update their addons and run with deprecation notices in production.

This is the one I really hope I’m misunderstanding. The way it reads it’s almost like you’re saying EL intentionally added code knowing that it may cripple some of their customer’s websites in order to get add-on devs to update their products. That can’t be the case though because that’s such a middle finger to your customers (not to mention add-on devs). “We know we’re gonna cripple your site, and especially those running custom add-ons, because you use an add-on that makes use of code we don’t want to maintain anymore”. That’s just absurd though so I truly hope I misread that. Please, can you clear this up? Was any concern or consideration given to existing customers and how these changes would affect their live website? What about those customers with custom add-ons (not available for sale) who have moved on from the initial developer?

I ask because more people are capable of updating EE (FTP, upload, go to URL and follow instructions; faster with DevDemon Updater) than are capable of modifying the custom add-on they commissioned all those years ago from a dev who has long moved onto something else. So with this deprecation strategy, EE is really hurting those customers (read: your own) way more than those of a commercial add-on dev.

Serious question, do you have a suggestion of how we can advance and clean up the code base, get rid of cruft, etc. without deprecating public methods?

Yes. Absolutely. There are ways. See the above example on JSON. Stop changing the API. Leave functionality intact and just modify the current functionality’s algorithms. Easy and no upset devs, and no upset customers, and no EE sites run amok with performance issues those customers are gonna complain about.

Believe me, I’m well aware of the deficiencies in the EE codebase and would love to see it updated, but you can do this without breaking the old things and certainly without adding additional performance penalties for sites without notice, awareness, or, if the above is actually the intent, so maliciously and recklessly.

And please feel free to email us when problems like this come up or you have suggestions. I’d like to think we can have a discussion without sarcasm, calling us insane or rude, and the general attitude of this post. It seems the attitude here is that we do not think about our decisions (your “capricious” claim), and they cannot be changed (ranting on a public forum instead of having a calm discussion with us to resolve it). This isn’t the case. Please email us if something isn’t working out or you’d like something explained, it’s the best way to foster change for the better and perhaps lessen your feelings of helplessness. I know it’s the trend online, especially Twitter, to bang a drum loudly, complain about our code, make claims as to why we made a decision or how its stupid, but that’s not productive. It would be more productive to go directly to the ones who can change it for you and have a calm discussion about coming to a resolution.

Lots there so I’m gonna take this point by point because I really think there’s some misreading going on.

First, I never said anyone (or company for that matter) was anything. I spoke in specifics about abstract stratgies and actions having issue. I’ve reread the initial post 4 times and can not, for the life of me, grasp how it could come off as me calling anyone anything. For example:

It’s sort of insane guys; a select for every deprecated function?

“It’s sort of insane guys”, in relation to the paragraph, is about the strategy of a SELECT on every deprecated function. And, come on man, any developer worth their salt knows it is. A strategy that involves the possiblility of unlimited looping SQL queries, with no sanity checks and no hard end in sight, isn’t a good strategy. How can it possibly be argued otherwise?

Another:

More, expecting your add-on developers, those who help make your product more useful to your customers, to add in boilerplate conditionals comparing EE versions throughout their code to accommodate a capricious deprecation strategy is just plain rude. I really don’t have a better way to describe how that feels. It feels straight rude.

I start out with a thought, add a statement that a given strategy is rude, add clarification, then wrap up by saying it feels rude. As in, the update to EE felt rude to me. Not, XX is rude. There’s a HUGE difference between a person being rude and an action feeling rude. One can, in fact, happen without the other.

The attitude of the post is based on the fact that EE added in 200 extra SQL queries to my site by moving from 2.5.5 to 2.6. Do you seriously not think that warrants a little anger? That I am unjustified in my feelings on this? How would you feel if this happened to you or one of your clients? Seriously. Imagine you paid good money for a car that got 30 miles to the gallon. Now, you get a tune up and all of a sudden your car can only go 5 miles to the gallon. Wouldn’t that just piss you off and make you want answers (at the least)? I’m flummoxed that there would be a defensive attitude because an update to your product, that I paid for, caused my site to quadruple in SQL requirements with no notice or warning. Now, as a developer myself, I can certainly understand the reluctance to want to own that the product your customer purchased had issues, and they are upset, but that solves nothing. There is nothing but upside to owning a mistake and nothing but continued issues if it’s ignored.

As to capricious, that’s in relation to how the deprecation strategy currently operates. There is no publicly available upfront notice when something will be removed, no clue as to what may be deprecated later, and no announcement as to the issues inherent in using the old funcitonality (even if/when we do know). That is capricious. Hell, it even fits the definition in relation to “unaccountable or sudden change” perfectly. Now, you EL employees, internally, may certainly have a strategy all pretty and written up on slides and one sheets that everyone knows about and discusses. Internally. Yay. Unless that’s public knowledge though it’s capricious behavior to the community because we have no clue just what’s going on and it’s always a surprise. How’s about a public list of functionality that’s to be deprecated in 2.7 or, even better, 2.7 AND 2.8/9? Problem solved. No one can claim they were taken by surprise. We all know, well in advance of release (or being invited to dev preview), what’s gonna be removed so we can avoid certain things. That would be amazing and hugely valuable to us devs actually.

I find it troubling that the fact I posted a message in a forum would be an issue worth bringing up. Hell man, it’s your forum for your product that I’m talking about and it’s even posted in the proper category. This is a clear cut case of what a “Development and Programming” post would include. It’s 100% about development and programming with your product. More, this is such a HUGE issue that public discussion was called for I think. For God’s sake man; an update quadrupled the SQL queries of my site!

That this is an issue, honestly Kevin, makes me think EL wants to hide the problems. “Upset customers shouldn’t post publicly so others can’t find out about the unhappiness and possibly hurt the reputation of EL for causing issues for customers.” That’s how it looks to me. I don’t get it and I’m incredibly turned off by it. Honestly, the idea of sending an email into a vacuum and hoping for a meaningful discussion in such a way as to effect change just doesn’t add up when compared to a public discourse where many viewpoints, experiences, and opinions can be covered and voiced. Personally, I’d much rather a public discussion, over a one to one, especially at the scale EE is at in terms of customers.

More, words fail me at describing the disappointment at the attitude that there’s some “trend” of criticizing EE on Twitter removed from legitimate angst and pain of your customers. Sooooo much of it is pure unhappiness at EL and EE yet, from what you wrote, I get the impression you guys write off all those issues because you don’t like the tone or medium used (or something equally small). These are your customers man. And they’re upset at the product EL sold them. Does EL seriously have so little love and/or respect for those that pay honest money for their product that all online discussion about said product is ignored? Is the team really so averse to criticism that the pains of their own customers is worth ignoring? As a developer who thanks my lucky stars I even have customers I find this attitude of “discussion in a vacuum” plain confusing. How can you possibly build the best product you can if you don’t engage your community and get open discourse from as many sources and viewpoints as possible?

Make no mistake here Kevin; EE increased the SQL needs of my site by almost 400% from an update of 1 point and that plain sucks. This is, by any definition of modern programming, unacceptable. I am unhappy and disappointed that EL would release something like this and then respond with such a defensive tone while not even offering a single insight or promise for a better future. Lots of excuses and reasoning but nothing to inform I was heard, the issue was taken seriously or that it won’t be repeated.

Bums me out man.

This is really only helpful if all add-on devs have access to the developer previews. Stating that you guys put up a list somewhere only a select few have access to and consider the matter handled reads reckless at best and disingenuous at worst.

This is why we’re asking more developers to be part of the dev preview program. In regards to putting up a list of deprecated methods, once again, that’s just how it works in the software world. A software release comes out along with a list of deprecated methods that is the developer’s responsibility to read.

You analogy to Hitchhiker’s Guide To The Galaxy is flawed. The situation there is “on display” was difficult to get to and in an unexpected place. In our case, deprecated methods are always put in the changelog which was easily available for download, why was that difficult?

The add-on that has the deprecated function calls that caused 200 SQL queries extra, I have come to find out, was not a part of that program. This can’t be the solution.

Yes ideally that wouldn’t be part of the solution.

As to the comparison with how PHP deprecates functionality you’re missing a crucial component: they advertise the changes for months and even years before it happens…More, PHP doesn’t add in a performance penalty for using deprecated code and it certainly has a way of disabling said notices…The comparison just doesn’t hold up unless you’re gonna follow their entire process instead of simply saying “they do so we do”.

Yes and that is part of the discussion we had internally, we were thinking of delaying the deprecation notices for after another release or two, and as I said before, possibly ways to disable the notices all together. I only brought that up since you said deprecations shouldn’t happen in point releases, so you missed a crucial component of your initial argument.

I disagree. Frankly, this is how developing with a framework works when the parent doesn’t take enough care with their community of developers. The good ones take care to never break the API and certainly wouldn’t add a performance penalty for not following the unknown and hidden deprecation strategy. For more information please read up on Semantic Versioning.

The paragraph you disagree with was directed to your point that developers shouldn’t have to put conditionals in their code to deal with deprecations, which you did not refute here, so I do not see how you disagreed with anything I’ve said. Once again you’re banging an old drum, I said in my earlier post that the performance hit is not what we intended, why are you still harping on this?

EE used to be such a joy to code for but with strategies like these that’s clearly becoming a thing of the past I see. Really disappointing response there man.

That’s the opposite of our intent, of course. For example, the Localize library was designed to be more of a joy to work with, but I understand you’re talking about the deprecation process.

Changing the API and removing existing functionality isn’t the only way to do this though. Really. I too want to use the JSON methods in PHP 5.2 just like the next guy but there’s absolutely NO reason for you guys to force this on the developers to do in their code. Doesn’t it make way more sense to have that logic in the EE code and leave the API alone? For example, checking for the right JSON function in the EE_Javascript library like so:

Sure that’s definitely a good strategy to use for a few releases, part of the suppressing deprecation notices thing I mentioned earlier.

No angry customers having their site run wild because an add-on dev somewhere in the world, who’s not even invited to the dev previews, didn’t know EE decided to change something.

All developers were publicly invited to the dev preview.

As a developer, which would you choose Kevin?

Of course I’d prefer an easier deprecation process which is why I’m trying to have a reasonable conversation with you.

This is the one I really hope I’m misunderstanding. The way it reads it’s almost like you’re saying EL intentionally added code knowing that it may cripple some of their customer’s websites in order to get add-on devs to update their products.

Yes that’s a misunderstanding. Our intent was not to cripple sites, the code was added with the thinking that deprecation methods WOULDN’T be called much because developers would fix their addons, it simply wasn’t designed for the case where folks would ignore these warnings and let them build up because that simply wasn’t a case we envisioned and yes that’s our fault.

Yes. Absolutely. There are ways. See the above example on JSON. Stop changing the API. Leave functionality intact and just modify the current functionality’s algorithms. Easy and no upset devs, and no upset customers, and no EE sites run amok with performance issues those customers are gonna complain about. Believe me, I’m well aware of the deficiencies in the EE codebase and would love to see it updated, but you can do this without breaking the old things and certainly without adding additional performance penalties for sites without notice, awareness, or, if the above is actually the intent, so maliciously and recklessly.

Thank you, this is the kind of information I’m trying to get.

First, I never said anyone (or company for that matter) was anything. I spoke in specifics about abstract stratgies and actions having issue…As in, the update to EE felt rude to me. Not, XX is rude. There’s a HUGE difference between a person being rude and an action feeling rude. One can, in fact, happen without the other.

If you call one’s actions insane or rude, it can be implied you are calling them insane or rude, I wouldn’t be so surprised to see me taking it that way here. We are effectively “EE” here.

“It’s sort of insane guys”, in relation to the paragraph, is about the strategy of a SELECT on every deprecated function. And, come on man, any developer worth their salt knows it is. A strategy that involves the possiblility of unlimited looping SQL queries, with no sanity checks and no hard end in sight, isn’t a good strategy. How can it possibly be argued otherwise?

We know that, please see my above answer to why this happened.

The attitude of the post is based on the fact that EE added in 200 extra SQL queries to my site by moving from 2.5.5 to 2.6. Do you seriously not think that warrants a little anger? That I am unjustified in my feelings on this? How would you feel if this happened to you or one of your clients? Seriously. Imagine you paid good money for a car that got 30 miles to the gallon. Now, you get a tune up and all of a sudden your car can only go 5 miles to the gallon. Wouldn’t that just piss you off and make you want answers (at the least)?

Sure I would be frustrated, but I wouldn’t let that dampen my ability to send an email like, “Hey guys, I just had the worst upgrade experience. Here’s what happened…this is obviously not ideal and is a real problem for many folks, is there anything that can be done to fix this?” I would never do this though.

I’m flummoxed that there would be a defensive attitude because an update to your product, that I paid for, caused my site to quadruple in SQL requirements with no notice or warning…There is nothing but upside to owning a mistake and nothing but continued issues if it’s ignored.

Once again, I’m not defending our usage of SQL here. And I hope you’re not implying we’re not owning up to mistakes. I said a couple times in my previous that we may have made some mistakes and I asked for your help. How do you think the issue is being ignored? I’m actively seeking your advice on this (not ignoring).

As to capricious, that’s in relation to how the deprecation strategy currently operates. There is no publicly available upfront notice when something will be removed, no clue as to what may be deprecated later, and no announcement as to the issues inherent in using the old funcitonality (even if/when we do know). That is capricious. Hell, it even fits the definition in relation to “unaccountable or sudden change” perfectly. Now, you EL employees, internally, may certainly have a strategy all pretty and written up on slides and one sheets that everyone knows about and discusses. Internally. Yay. Unless that’s public knowledge though it’s capricious behavior to the community because we have no clue just what’s going on and it’s always a surprise. How’s about a public list of functionality that’s to be deprecated in 2.7 or, even better, 2.7 AND 2.8/9? Problem solved. No one can claim they were taken by surprise. We all know, well in advance of release (or being invited to dev preview), what’s gonna be removed so we can avoid certain things. That would be amazing and hugely valuable to us devs actually.

Thank you for the clarification, that helps. I’m not sure what we can do about a public list but it’s an idea, I can bring that up with the team as well.

I find it troubling that the fact I posted a message in a forum would be an issue worth bringing up. Hell man, it’s your forum for your product that I’m talking about and it’s even posted in the proper category. This is a clear cut case of what a “Development and Programming” post would include. It’s 100% about development and programming with your product. More, this is such a HUGE issue that public discussion was called for I think. For God’s sake man; an update quadrupled the SQL queries of my site! That this is an issue, honestly Kevin, makes me think EL wants to hide the problems. “Upset customers shouldn’t post publicly so others can’t find out about the unhappiness and possibly hurt the reputation of EL for causing issues for customers.” That’s how it looks to me. I don’t get it and I’m incredibly turned off by it.

If you wanted to foster real change, I would have expected you to email us instead of posting in the forum. As you can probably tell, we’re not in the forums too much, the developers are busy writing code, and the support team is now mostly in the private support queue. The forums are heavily run by the community now. Therefore, if you wanted to contact us, why not go about the most direct means which ensures interaction with us? The fact that you didn’t seemed to me that you just wanted to cause drama publicly, but if that’s not the case, I’m sorry to read it like that.

Honestly, the idea of sending an email into a vacuum and hoping for a meaningful discussion in such a way as to effect change just doesn’t add up when compared to a public discourse where many viewpoints, experiences, and opinions can be covered and voiced. Personally, I’d much rather a public discussion, over a one to one, especially at the scale EE is at in terms of customers.

Have you had a bad experience emailing us? I’m sorry if you have, but we’re generally very good at replying to reasonable emails. Once again, I only made that comment because of how our attention is divided at the moment. If you want to reach us, it’s best to email. If you want to have discussions in public, that’s fine too, but if they’re directed at us without notifying us, we may not see it right away. That’s all I was saying.

More, words fail me at describing the disappointment at the attitude that there’s some “trend” of criticizing EE on Twitter removed from legitimate angst and pain of your customers. Sooooo much of it is pure unhappiness at EL and EE yet, from what you wrote, I get the impression you guys write off all those issues because you don’t like the tone or medium used (or something equally small).

We take the valid concerns seriously. But if someone is making an unreasonable or false claim, or an otherwise snarky comment in hopes to gain a high five, then no that’s not a substantive argument worth listening to. Moreover, if they’re going to just complain to the ether instead of working with us to make a change, how can we help? Then there’s the argument of what happens when you try to please everybody which I’m sure you’re aware of.

These are your customers man. And they’re upset at the product EL sold them. Does EL seriously have so little love and/or respect for those that pay honest money for their product that all online discussion about said product is ignored?

No that’s not the case, of course. Please provide an example if you have one.

Is the team really so averse to criticism that the pains of their own customers is worth ignoring?

No we’re not ignoring valid criticism. I’m not sure what I said in my earlier post to make it sound like we don’t care, can you let me know why you’re taking the conversation in this direction?

Why do you frequently default to malice in our intent?

As a developer who thanks my lucky stars I even have customers I find this attitude of “discussion in a vacuum” plain confusing. How can you possibly build the best product you can if you don’t engage your community and get open discourse from as many sources and viewpoints as possible?

Once again, that’s what I’m trying to do here. I didn’t say, “please take this conversation offline,” I’m only offering suggestions on the best way to reach us, the people who can make the change.

Make no mistake here Kevin; EE increased the SQL needs of my site by almost 400% from an update of 1 point and that plain sucks. This is, by any definition of modern programming, unacceptable.

I’m not arguing for a 400% increase in SQL needs.

I am unhappy and disappointed that EL would release something like this

Do you ever ship bugs?

and then respond with such a defensive tone while not even offering a single insight or promise for a better future.

If you’re on the offense, then of course I’ll be on the defense provided I have the backup necessary. If I don’t, I willingly admit a mistake was made, which I did. If someone is making an argument against us and we have a counterpoint, can we not share it? We’re not defensive for the sake of being defensive. If we believe in a decision we’ve made and you have NOT provided a proper argument against it, then we’ll defend ourselves. Please let me know why this isn’t ok.

I DID provide an insight to the future, I said we’ve been discussing ways internally to make this better, and I must be asking your advise for a reason, right?

Bums me out man.

I’m disappointed as well. I really feel like most of your response was either taking something I said the wrong way (some could be blamed on me) or you just didn’t read what I wrote. Your response also makes unreasonable assumptions of malicious intent on our part and criticizes our choice to defend select decisions. I think you’d be surprised at how much we agree on things. I agree deprecations should be handled better. Perhaps you’re taking my position as one that believes the current process is fine. It may have sounded like that because your position sounded like deprecations shouldn’t happen at all, so I was defending deprecations in general. That led to your long tirade about our process and SQL.

To clear things up and summarize, we would like to make the deprecation process better, hence why I’m asking for your input. Yes, we know SQL usage shouldn’t increase 400% and it’s not ideal. No we’re not ignoring public discussions, it’s just not the ideal way to direct them at us. No there is not as much malice in our intent as you seem to think. I think if we could concentrate on the task at hand and not belabor other extraneous issues, it would be a good use of our time.

Back to deprecations, it sounds like much of this would be solved if we were to simply delay method deprecation notifications in the CP for a few more releases. Maybe we say, “this method is now deprecated as of 2.6” but then don’t start showing notices until say…2.8? Is an acceptable solution and timeframe for method deprecations?

Back to deprecations, it sounds like much of this would be solved if we were to simply delay method deprecation notifications in the CP for a few more releases. Maybe we say, “this method is now deprecated as of 2.6” but then don’t start showing notices until say…2.8? Is an acceptable solution and timeframe for method deprecations?

What we do in our products is first to check the popularity of the item we want to deprecate. Depending on the outcome, we decide how to proceed.

The first step is to add the new functionality, and adapt the item to use that, exactly like the json example above. We put out a notice that there is new functionality available, which should be used instead of the old one, and that the old one is candidate for deprecation.

Next step (in a next release, or if it’s very popular or difficult to adapt maybe in two or three releases) is to formally deprecate it, and have it write a deprecation message to the log.

Final step, again in a release following on that we will remove the deprecated functionality. This will NEVER be a point release, within point releases API backward compatibility is guaranteed, stuff that is deprecated will only be removed on the next major release (of which you can expect things will be different).

Sofar, this mechanism has worked quite well.

Key points are: communicate early, and communicate often. Give people time to adapt. And be clear about the roadmap (with regards to the deprecated item), it avoids suprises for those using it.

hmm…

seems the faults of this forum has just been extended to not being able to delete your own post…

As a end-user of EE and the add-ons (and a long time EE developer), I was quite surprised to see all the deprecated functions as well. This is extremely frustrating for a web developer, like myself, as we are at the mercy of the add-on developers. And now I am stuck in a sort of limbo, here.

Quite honestly the changes that were made to a dot release seemed like poor planing. Just the way the new relationships were handled, heck the change was not even noted in the end user docs.

Quite honestly I am hoping that Pixel and Tonic will be better than EE, because lately I have felt that EE has dropped the ball one too many lately.

Just my .02 Joe

Key points are: communicate early, and communicate often. Give people time to adapt. And be clear about the roadmap (with regards to the deprecated item), it avoids suprises for those using it.

Thank you WanWizard, sounds like good advice.

Quite honestly the changes that were made to a dot release seemed like poor planing. Just the way the new relationships were handled, heck the change was not even noted in the end user docs.

Sorry you’re having trouble. Can you provide an example of how the documentation is lacking? With your help, we can fix it.

Quite honestly I am hoping that Pixel and Tonic will be better than EE, because lately I have felt that EE has dropped the ball one too many lately.

Do you operate on the premise that one should be punished for a few perceived missteps rather than hope for their improvement and well being? That kind of attitude will not help anyone. Pixel & Tonic has the luxury of having fewer customers to support and less time having a product out in the market that is a major framework. You’re free to use whomever you want of course, but you’re comparing apples to oranges at this point.

Key points are: communicate early, and communicate often. Give people time to adapt. And be clear about the roadmap (with regards to the deprecated item), it avoids suprises for those using it.

Thank you WanWizard, sounds like good advice.

Quite honestly the changes that were made to a dot release seemed like poor planing. Just the way the new relationships were handled, heck the change was not even noted in the end user docs.

Sorry you’re having trouble. Can you provide an example of how the documentation is lacking? With your help, we can fix it.

Yes, see ticket 72958. Its well documented. Basically you guys released 2.6 and barely a mention that Relationships were completely re-written. Also you eliminated all the documentation of 2.5.5 thus I spent three days trying to fix a relationship issue (and 2 days with your tech support) until they realized I had 2.5.5 and I was using code from 2.6

Do you operate on the premise that one should be punished for a few perceived missteps rather than hope for their improvement and well being? That kind of attitude will not help anyone. Pixel & Tonic has the luxury of having fewer customers to support and less time having a product out in the market that is a major framework. You’re free to use whomever you want of course, but you’re comparing apples to oranges at this point.

Well no, but when 2.6.1 is having alot of issues and one issue in particular that has brought down a live site (see http://ellislab.com/forums/viewthread/235313/) which is supposed to have been fixed in 2.6.1 and now my site is down AND your support is ticket engine is down as well, and I have to wait until Monday to get it fixed.

Also the deprecated function issue does seem pretty big, quite honestly I dont understand why you couldnt release new functions while preserving old syntax.

Joe

Yes, see ticket 72958. Its well documented. Basically you guys released 2.6 and barely a mention that Relationships were completely re-written. Also you eliminated all the documentation of 2.5.5 thus I spent three days trying to fix a relationship issue (and 2 days with your tech support) until they realized I had 2.5.5 and I was using code from 2.6

Ah ok, yes sorry about our support system being down, I can’t view the ticket either. We moved to a new server last night to help with the site speed issues seen lately and our support system is having trouble. However, in case you missed this recent change, you should be able to download documentation for 2.5.5 here:

http://ellislab.com/expressionengine/user-guide/

Just click on the dropdown at the top and select 2.5.5. And there was more than barely a mention of Relationships being changed, it’s the featured article on our homepage and it was prominent in our changelog, I’m sorry if you missed it.

Well no, but when 2.6.1 is having alot of issues and one issue in particular that has brought down a live site (see http://ellislab.com/forums/viewthread/235313/) which is supposed to have been fixed in 2.6.1 and now my site is down AND your support is ticket engine is down as well, and I have to wait until Monday to get it fixed.

I’m sorry this one bug has made you wish ill against us. It looks like Derek replied to your comment on the bug thread, can you please try his suggestion and respond to that? He is trying to help you.

https://support.ellislab.com/bugs/detail/19321/#10741

Also the deprecated function issue does seem pretty big, quite honestly I dont understand why you couldnt release new functions while preserving old syntax.

It’s not a question of whether or not we can, we just simply didn’t do it, and as I’ve said, we’re willing to reevaluate our process for deprecating methods as long as we have folks willing to cooperate in a discussion about it.

Kevin,

Thanks. For some reason I didnt get notification of the reply so I didnt know about a possible solution. It did work.

Sorry its just a little frustrating for me. I first had issues with the new relationship stuff, I didnt know I could still access 2.5.5 docs, even Kevin Smith said they were unavailable. Then I had the issue with not being able to edit entries after my 2.6.1 issue and I still have all the errors in the log file which who only knows the add-on developers will ever fix that.

Joe