5 ms·

Pardon the rant, but I feel that the advantages don't outweigh the fact that with each release some of my stuff gets broken and I need to adjust. Django puts De

by d33 6y ago

Pardon the rant, but I feel that the advantages don't outweigh the fact that with each release some of my stuff gets broken and I need to adjust. Django puts DeprecationWarnings basically everywhere and it's a hell to maintain projects that had been alive for a few years. God forbid you do anything with the interfaces they expose. The problem is only getting worse when you consider your dependencies, which in many cases don't keep up with the release cycle of Django. It's a mess.

rbanffy 6y ago
I tend to keep one CI pipeline with all dependencies unpinned (I made pip-chill for that reason) and Django set to the latest version to get early warnings of the impending doom. That said, it takes a while for the Django folk to end support for a release so, at least, there is not much of a hurry to update a running app.
orf 6y ago
Can you elaborate on some of the things you've been frustrated with? I find Django has a pretty solid deprecation policy, with the goal being that if you have no deprecation warnings then upgrading is simple. Third party dependencies do get in the way of that sometimes though.
metafunctor 6y ago
My experience has been good, with a Django app maintained for over 8 years now. We've only updated Django when a new LTS version is out. That means once every two years there's an update that may break something, but I don't remember it ever being more than a few hours of work. We do take some care to (mostly) only use documented interfaces, so maybe that helps?
danpalmer 6y ago
> Django puts DeprecationWarnings basically everywhere This seems like exactly the way that deprecations should be handled. Are you suggesting they should maintain backwards compatibility for much longer? They already have a pretty long deprecation policy.
djaychela 6y ago
I'm only a beginner with Django, but I tend to agree to a point - reason being is that I've found old code that I want to use (github, etc.), but it targets Django 1.x (later versions, say 1.10), and will use a load of stuff which is now removed. The issue I've had is that the documentation seems to be difficult to find these removed elements - such as last week, looking for the {% ssi (file) %} tag, which it took me the best part of an hour searching to find out which version it came from - and indeed that it was a standard tag! A lot of the imports seem to move around (which is easy to fix, once you know where they now are), and some things have just vanished. I know documentation is a nightmare to produce, but there must be a way to automatically produce it for either import relocations or deprecations so you can find things like this easily?
- Daishiman 6y ago
  Sorry, but Django is the best framework I've found for managing deprecations. In the web world it's quite frequent to have major versions every couple years that break everything and require substantial dev cycles to keep up. That said, 1.x applications are quite old by now.
Alex3917 6y ago
For me, upgrading Django for a series-A sized startup (e.g. 25KLOC) takes maybe 2 - 4 hours on average, assuming there is good integration test coverage. What parts of the upgrade process are you finding take a long time? I feel like the last Django release that was at all complicated to upgrade to was maybe 1.9, in terms of getting the test cases to run properly in parallel if they hadn't been properly isolated. And even that was more of a Python3-like situation, where it really only exposed things that people had done incorrectly previously.
WD-42 6y ago
I'm sorry, but this is just programming. You have two choices: 1. Never upgrade and keep everything stable but go through hell when you inevitably must update something or 2: keep up with the latest and go through some minor pain with every release. It's a lot like taking care of a house or car. The world does not stand still, much less programming frameworks.
- zelphirkalt 6y ago
  Hmmm, with well chosen, thought through abstractions, which only presume the minimum they need to presume about their usage, the frequent changes you describe are not a given. The question is, what it is, what frequently needs to change and why no appropriate abstraction has been found to reach stability.
  - WD-42 6y ago
    We're talking about a huge web framework here. Your comment might apply to small isolated pieces of code. But Django is built on top of thousands if not millions of abstractions. It's absolutely unreasonable to think that it won't change.
neurostimulant 6y ago
Compared to how fast things move in frontend world, Django feel like ultra stable to me. Upgrading an old django project to the latest version typically doesn't affect any fundamental things. Maybe some classes has been moved into contrib or spin off as non-core packages, or some methods has been removed and replaced with another methods, but never fundamental changes that requires you to rewrite majority of your code.

by d33 6y ago

rbanffy 6y ago

I tend to keep one CI pipeline with all dependencies unpinned (I made pip-chill for that reason) and Django set to the latest version to get early warnings of the impending doom. That said, it takes a while for the Django folk to end support for a release so, at least, there is not much of a hurry to update a running app.

orf 6y ago

Can you elaborate on some of the things you've been frustrated with? I find Django has a pretty solid deprecation policy, with the goal being that if you have no deprecation warnings then upgrading is simple. Third party dependencies do get in the way of that sometimes though.

metafunctor 6y ago

My experience has been good, with a Django app maintained for over 8 years now. We've only updated Django when a new LTS version is out. That means once every two years there's an update that may break something, but I don't remember it ever being more than a few hours of work. We do take some care to (mostly) only use documented interfaces, so maybe that helps?

danpalmer 6y ago

> Django puts DeprecationWarnings basically everywhere This seems like exactly the way that deprecations should be handled. Are you suggesting they should maintain backwards compatibility for much longer? They already have a pretty long deprecation policy.

djaychela 6y ago

I'm only a beginner with Django, but I tend to agree to a point - reason being is that I've found old code that I want to use (github, etc.), but it targets Django 1.x (later versions, say 1.10), and will use a load of stuff which is now removed. The issue I've had is that the documentation seems to be difficult to find these removed elements - such as last week, looking for the {% ssi (file) %} tag, which it took me the best part of an hour searching to find out which version it came from - and indeed that it was a standard tag! A lot of the imports seem to move around (which is easy to fix, once you know where they now are), and some things have just vanished. I know documentation is a nightmare to produce, but there must be a way to automatically produce it for either import relocations or deprecations so you can find things like this easily?

Daishiman 6y ago
Sorry, but Django is the best framework I've found for managing deprecations. In the web world it's quite frequent to have major versions every couple years that break everything and require substantial dev cycles to keep up. That said, 1.x applications are quite old by now.

Alex3917 6y ago

For me, upgrading Django for a series-A sized startup (e.g. 25KLOC) takes maybe 2 - 4 hours on average, assuming there is good integration test coverage. What parts of the upgrade process are you finding take a long time? I feel like the last Django release that was at all complicated to upgrade to was maybe 1.9, in terms of getting the test cases to run properly in parallel if they hadn't been properly isolated. And even that was more of a Python3-like situation, where it really only exposed things that people had done incorrectly previously.

WD-42 6y ago

I'm sorry, but this is just programming. You have two choices: 1. Never upgrade and keep everything stable but go through hell when you inevitably must update something or 2: keep up with the latest and go through some minor pain with every release. It's a lot like taking care of a house or car. The world does not stand still, much less programming frameworks.

zelphirkalt 6y ago
Hmmm, with well chosen, thought through abstractions, which only presume the minimum they need to presume about their usage, the frequent changes you describe are not a given. The question is, what it is, what frequently needs to change and why no appropriate abstraction has been found to reach stability.
- WD-42 6y ago
  We're talking about a huge web framework here. Your comment might apply to small isolated pieces of code. But Django is built on top of thousands if not millions of abstractions. It's absolutely unreasonable to think that it won't change.

neurostimulant 6y ago

Compared to how fast things move in frontend world, Django feel like ultra stable to me. Upgrading an old django project to the latest version typically doesn't affect any fundamental things. Maybe some classes has been moved into contrib or spin off as non-core packages, or some methods has been removed and replaced with another methods, but never fundamental changes that requires you to rewrite majority of your code.