(Yes, "a rant," but an informed one ...)

One of the things that I do for fun is to build and run a few web sites for a few clubs. Generally, once the site is running I just leave it alone. But sometimes I do have to update and service them – for example, when the hosting company makes a major change to the environment.

I use the "Django" (Python) web framework for these, largely because it has a rich and plentiful library of components that you can simply stitch together. But there is a wee problem: deprecation.

"Change for the sake of change," and you remove what used to work. A simple example is that, in Django, the way that you "obtain the tzinfo of the place where the server is now running" has changed three times, one of them quite recently. And some of the packages which I use did not. The key problem is that the Django people didn't simply "leave in" the old way of doing things. Maybe they thought that "the new way" smelled or tasted better, but it actually wasn't any different. It was just different. Different in a way that breaks my code – and the code of other people upon whom I rely, some of whom aren't maintaining that code anymore or who haven't yet caught up.

Another very frightening event was when I was "updating the system requirements" and found that one package had been removed from the repository altogether. Yes, I found another copy of it elsewhere. But I really don't believe that the repository owners were "running out of disk space" or something. If you published it, leave it there. Somebody might still need it. Somebody like me.

Another "rant" has to do with the PHP language itself. I and my teams spent about a year(!) moving a set of websites from PHP-5 to PHP-7. There were two big "breaking changes." One was that the entire SQL interface – which is "built in" to that language – was replaced. And the old one was "deprecated," which is to say, "removed." They used an entirely new set of function-names, and the new design was much better, but they could not drive themselves to leave the old one in so that I could migrate in a more-orderly way.

But a much sillier change had to do with the functions which PHP uses to match regular expressions. They took out the old ones completely, and replaced them with two new ones which did the same thing except(!) that the order of the parameters – arbitrary to begin with – was reversed. (I solved that problem by putting the old functions back, but it was still a change that affected hundreds of application modules.)

The complication which really set the coffin-nail was that Linux distributions stopped furnishing PHP-5. And, they never contemplated any "clean" system by which PHP-5 and PHP-7 could exist alongside one another. So, when you "upgraded" their Linux from one major-release to the next ... "everything(!) broke."

Why don't the developers of important components – and, languages – recognize the value of "let a sleeping dog lie?" If you once wrote it one way, you really can afford to "leave the old way in place" as you create another way that smells or tastes better to you. The longer your successful system is out there, the more is the impact of your "changing 'tastes.'" To an awful lot of people whom you will never know. You are requiring people to spend money(!) simply to stay right where they are.

Likewise, "distro" designers. Think about the present as you plan for the future. People generally do want to follow new distro releases in order to get very important things like security and kernel changes. But they literally cannot afford it if "everything breaks." My client paid several hundred thousand dollars(!!) to me and my teams in order to ... stay where they were. While I certainly appreciated the money, why did they have to spend it, let alone "spend it in a hurry?" Well, it was all because of: deprecate.

TLDR: It's less to do with "the devil", and more with the fact some money hungry people develop solutions before there's a problem.
Later on, they'll simply bribe others to create a problem on multiple fronts, and say, well, luckily for you it just so happens that there's a solution.
And because the old stuff is unaffected by the new, expensive problems.. it is now 'deprecated' since all it does is detracts deployment of new, expensive solutions.

It's sad. This is one of the ways that Microsoft seems to be ahead in the field. They have a claim to backwards compatibility for 20+ years now. API changes and "game breaking" changes happen in open source regularly. Nature of the beast though. People make what they want. They don't get paid for it so to speak so they have no incentive to no keep it a certain way. If they want to change it then they go ahead.

OP talks about Django and PHP; as far as I know both are free as in beer as well as in speech. So how are "money hungry people" relevant here?

That's not specific to any projects, but happens all the time.
See also; anti-malware authors creating self-deprecating malware in their spare time..
Not sure if funny, or sad. Just saying.

What elcore says isn't directly relevant in these examples, though is certainly the case in other places. However, that doesn't mean increasing profits isn't the driving factor in what sundialsvcs is complaining about.

Jet Brains - who sell IDEs - are the primary corporate member of Django Software Foundation - the more a language changes the easier it is to convince people they need a new tool to deal with that language.

Zend is a major contributor to PHP, and also sell tools and support. By encouraging high release turnover, they can encourage people to pay them for supporting older releases.


It may also be an over-abundance of boredom - there are people who seem to like change for the sake of change, and choose to mess with things that are working.

Other times, there are people who simply don't understand how low-overhead features/data can be, and believe that removing things they don't use makes something better.


Of course, all of this is talking about removal, not deprecation. Deprecating is useful in documentation to indicate when older functionality may no longer be the best known way to achieve something - it's important for people learning to not get overloaded - but it seems a lot of developers don't understand what deprecation actually means, or that it is not required to remove deprecated functionality.

The biggest problem is when there's a high release turnover combined with features being deprecated and removed in a timespan smaller than most people want to upgrade in.

Zend owns PHP. Therefore, they can do with it whatever they like – and, they do.

I have no complaints about the Django platform, either: it's one of the all-around best frameworks I have ever used. But, when you "deprecate" a feature and replace it with a "just different" version of itself, you're just creating extra work for people who might just want to "stay right where they are."

PHP for example could have two functions that match a regular expression. They could have added the new one and left the old one in.

The PHP project that I referred to had over 10,000 source files in it and supports more than 250 URLs which are in fact carbon-copies of one another except for "skin." I had to create automated tools to perform some of the necessary modifications because there were simply too many files to change by hand. But, when all was said and done, the web sites had not "changed." All of the changes were forced upon me by differences between PHP 5 and PHP 7, but no functionality was added. The sites "stayed right where they are." When we flipped the switch, nothing was visually or functionally different than before.