Pascal, I don't think anyone here disagrees with your overall goal to reduce the breaking changes. As someone that got handed a 1.2 project with zero tests and updated it to 1.8, good test coverage to lay the foundation for reviving an ambitious project that went comatose before being prioritized again, the amount of breakage and updating required was surprisingly small. It took about a month or so to do, and a quarter of that was setting up staging and prod environments on AWS. The core devs here have done a great job, in my opinion, of keeping the breaking changes to a minimum, and making them in a thoughtful manner with an eye to the future.
Tech debt is a very real thing. Keeping it under control is vital to the pace of improvement and updates for any project, large, middling or small. Any project requires maintanence at minimum, just like owning a car or house. If you buy a car and run it every day for five years, only filling up the gas tank and adding a splash of oil now and then, you don't have any excuse to be upset at the mechanic or manufacturer for the size of the repair bill when things start breaking. At least with software, its alot easier to get fixes out than with hardware. You make a persuasive argument and have great passion, but the overall goal of enabling out of date and unsupported releases to remain around longer than they should be makes me feel really uncomfortable. A spftware project is not buy once and forget, neither is a car. And your package seems to encourage that lax practice to a level that I would be highly resistant at working at a company if I couldn't persuade management to prioritize keeping up to date and tech debt at a manageable level. Open source has a pretty low barrier to entry, and django projects like the ones you listed on django packages are reflective of that. Its easy to make a package and put it out, but maintaining and iterating and releasing take alot more in terms or time, effort and emotional state. Fortunately, Python as a whole seems to be much easier on package devs than the JS community, but as I'm sure Carlton, Adam, Tim, and anyone that's published a package with requests for support can attest, it can get exhausting. That's when packages just die on the vine. Some are lucky to be resuscitated by another dev taking over, or forking the original, but that doesn't happen for the majority. Deliberately going out of your way to ensure that old code which hasn't been looked at in however long and was last working on two LTS releases ago gives me a very squicky feeling in my stomach. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/097ecac4-0596-40d4-a069-7e8d2c879ce9%40googlegroups.com.
