The Right Solution for that is officially supporting Python 2.old in Django 1.old, and eventually backporting minor features/fixes in Django 1.old. The tradeoff here depends on what takes the most development time: Backporting features and fixes, or hacking compatibility with an old version of the language.
With a solid, automatized regression suite; good version/branch management (when is Django moving over to git?) and a Generally Good Codebase, this is never an issue and I don't believe it would be an issue with Django. While I know Django 1.0 is still somewhat supported, focusing efforts on such management also enables developers to tackle another issue raised earlier here. Upcoming stable releases should NEVER cripple development of future features and other changes that won't make such a release. Unfortunately, it's what happened in 1.1 and what is currently happening. J. Leclanche / Adys On Mon, Apr 5, 2010 at 10:48 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Mon, Apr 5, 2010 at 3:30 PM, Jerome Leclanche <adys...@gmail.com> wrote: >> If you're going to use such an ancient version of a distribution, you >> are only crippling yourself. As you said yourself, you should move on; >> if someone is using Python 2.3, they can use Django 1.1/1.2. If they >> want all-new 1.3 features, then updating Python/distro should not be a >> roadblock. >> >> This is a common issue in software backwards compatibility, and I'm at >> least one to think that just because someone, somewhere still uses an >> old version of python, they can't also keep using an old version of >> Django. > > I agree -- to an extent. > > I have no problem with the argument that you can't expect to be able > to walk the leading edge and the trailing edge at the same time. > > That said, the problem here is that the users that are most affected > by backwards incompatibilities and version deprecations are the users > with the most economic clout - "enterprise" users. For better or > worse, large organizations have inertia when it comes to adopting core > infrastructure, and it can be difficult to get this core > infrastructure updated. However, large organizations also have the > biggest potential to grow the adoption of a framework like Django and > move it into the mainstream. This is especially important while we're > adding features that are of the most interest to enterprise users, > like multiple database support. > > While we don't want to completely hamstring development of Django by > requiring support for ancient Python versions, we also don't want to > limit the adoption of Django by large organizations simply by making > arbitrary demands on core infrastructure, or by breaking backwards > incompatibility of core features. > > It's a fine line we have to walk between being an innovative framework > and supporting the users that have helped us get to where we are. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
