4 ms·
> Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate y
by epalm 4y ago
> Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate your development time.
Many years ago I used to write projects with Python/Django. The Django project releases 3-year LTS versions with 3-month overlap. LTS versions are supposed to ease the constant upgrade overhead, and hitting a 3 month window every 3 years doesn't seem too bad, especially when they also release documentation specifically guiding you from one LTS version to the next. Does Ruby/Rails not do this?
- phendrenad2 4y ago3 years isn't all that long. There's still Fortran and Cobol in the wild from 40 years ago. Most people in silicon valley will have worked on a 20 or even 30 year old codebase at some point. And why do I need to upgrade Django? Did the fundamental principle of MVC change? No, the developers of Django just didn't like some Python 3.8 syntax and decided to rip it out and replace it with some shiny new thing in 3.9. They stopped backporting security fixes to the old Django version, the one with the totally-gross Python 3.8 syntax. So now, to use the latest Django version, you need to upgrade Python minor version also. Easily avoided if you rolled your own framework. (Of course, sometimes you don't have a choice, because maybe Python deprecated some perfectly-good syntax between 3.8 and 3.9 because the devs didn't like it anymore). Another thing is, that's every 3 years for Django. If you start stacking other 3rd party dependencies on top of Django (even something as simple as a MongoDB ORM), you'll have a separate, secondary upgrade schedule for that library.