> Why shouldn’t they use stable technology they are proficient with?
This perspective is one of the major indicators of an engineer with more experience managing real projects. Making a technology choice or transition is a milestone/roadmap affecting decision. To do so for preference over deliverability has killed many a project.
Eh, I'm pretty sure Backbone and Knockout are more stable than React :) They didn't have a release since 2019.
I mean, React itself is quite fine with backwards incompatibility. But how many completely backwards incompatible versions did react-router have? I think there four, but I can be wrong.
All of this - and maintenance. The house that may be "inexpensive" re: sale price may cost just as much to fix. The cost of fixing X sq ft of thing or replacing appliance Y may certainly increase with the size of the home, but even small homes can have major expenses (and if you are in a "cheaper" area this means more home for less, so more to fix).
Lack of regulation in places without rigid building code enforcement can also make it hard to find people who aren't hacks (if you can find people at all) in construction.
Comcast may add a modem rental fee to your bill automagically even if you have your own modem (even if you have always had your own). This happened to me and the phone support told me they do this intentionally and they expect people to call and resolve it if it is not an appropriate fee.
For the sake of your time and your sanity you should do neither of those things. You should file a complaint with the appropriate state labor body, particularly in a US state like CA where the agencies are well funded. The chance of it benefiting you is virtually nil, but the chance of it causing pain for the employer - hopefully forcing them to change their ways - is non-zero.
Outside the US I have no knowledge of at what level those protections may/may not be enforced (but hopefully somewhere).
That's surprising to me as I have updated a large production Django code-base on my own for every version from 1.5 to 2.0 and it has never taken me more than a day, with an equal or lesser (typically lesser) amount of time dedicated to deprecations when I updated to the previous version. Any blockers past that point have always been due to slow-to-update third-party libraries.
The Python 3 update took longer and had a longer legacy of surprise breakages, but I don't ding Django for following the intended life cycle of Python.
I'm surprised you're surprised. Have you seen the size of the breaking changes documented with each release notes? We typically hit about 10 of these changes per release, sprinkled all over our code.
And those are just the intentional breaks. We find a lot of unintentional breakage too, and sometimes we accidentally use undocumented stuff which of course also isn't documented when it breaks. Each Django release has added an average of 32 commits per release for the past four releases just to deal with the version upgrade.
Some things to do that could help everyone (this is what I do):
If documented stuff changes, Please report it (though that likely means testing against the alpha / beta versions (or just master). Keep Django honest.
If you find yourself using undocumented features, consider documenting them; that way they’re held to backward compatibility.
Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.
Disclaimer: Core dev now, though I had this attitude before that too.
I've encountered very little sympathy from Django developers. Everyone seems to have just accepted that it breaks often and it's totally my fault for not keeping up with the breaking changes. Everyone seems to think that Django breaking compatibility all over the place is good, proper, acceptable, and inevitable. Nothing is sacred, anything can break, and make sure you go through that list each release to see what you have to change in your code.
I think it would help if you bring it up on the Django-developers mailing list, if you haven't yet. I think that would help raise awareness about the issue, and I hope it would lead to some policy changes.
My guess here is that still being in Python 2 makes this more difficult.
If you're in Python 2 the bytes/str story is still mixed up, so API solidification happening in Django iteratively (in preparation for Django 2.0) will likely break a good amount of your code.
Inversely, we moved over to Py3 in the 1.7 days so we were spared some pain on that end.
For US Generation Student Debt, there's a significant long-term cost to that decision. If you don't have to double the years it takes you to pay back your debt to do so, maybe moving abroad is more of an option.
Beyond the obvious etymology that others have stated, the terms "sanctuary", "refuge", and "preserve" are used far more by the US to represent the idea you describe for animals, so the equivalence in terminology doesn't seem well founded at all.
Was not stated.
> Why shouldn’t they use stable technology they are proficient with?
This perspective is one of the major indicators of an engineer with more experience managing real projects. Making a technology choice or transition is a milestone/roadmap affecting decision. To do so for preference over deliverability has killed many a project.