I don't see how it should be up to Django to continue to support all of these archaic versions of Oracle. To paraphrase the mantra repeated during various mssql discussions, "Django doesn't need to include everything in core, it just needs to make it possible for others to implement". If people feel strongly about staying on a no longer supported version of Oracle, then they can either stick with an older version of Django or create django-decrepit-oracle.
Django should strip this legacy code. Regards, Michael Manfre On Sat, Jun 14, 2014 at 10:01 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > > > > On Sat, Jun 14, 2014 at 5:49 PM, Russell Keith-Magee < > russ...@keith-magee.com> wrote: > >> >> On Sun, Jun 15, 2014 at 7:51 AM, Shai Berger <s...@platonix.com> wrote: >> >>> Hi guys, >>> >>> TL;DR -- ...sorry, there's no TL;DR here. It's a bunch of separate >>> ideas. It's >>> a little lengthy. Please bear with me. >>> >>> I'd like to compare our support for old database servers with our support >>> for old browsers. We only recently dropped code that supported IE 6/7 (!) >>> for a security (!) fix, and even that decision wasn't taken trivially. I >>> don't >>> think suggestions that will break Django sites for IE8 users will be >>> appreciated, unless there is a great benefit on the other side. And IE8, >>> along with the OS which required it, are long EOL'd. >>> >>> I also don't subscribe to the position that it's irresponsible to claim >>> support >>> for EOL'd products; by the same token, the reponsible thing would be to >>> include, by default, a middleware that sends warnings to users of old >>> browsers. We don't do that, because we're all consenting adults here. >>> And on that comparison, the old browser is arguably more of a risk than >>> the old database server -- the db, most likely, is not directly >>> accessible >>> from the internet. >>> >> >> There's another, more important difference, though. The database server >> is under the direct control of the developer. If I'm a developer, I'm >> actively choosing Django X, and I choose MyWonderDB 1.2.3. If I make a >> decision to upgrade to Django Y, the fact that my database is no longer >> supported is part of that decision - I either need to upgrade my database >> as well, or I need to evaluate whether "not supported" means "will actually >> break" or "might work, but we just aren't testing for it", and take the >> risk (and the related testing responsibility) onto my own project. >> >> However, the website that I deploy is accessed by people whose software >> isn't under my control. People are still using IE6. Never mind that it's >> been EOLd; you'll pry their copy of Win95 out of their cold, dead hands. >> This long tail is essentially endless - as a web framework, when we drop >> support for a browser, we're talking about how much of this tail we're >> willing to cut off. IE8 may well be EOL, but Microsoft adoption rates and >> upgrade policies mean that there is still s substantial population using >> it, especially in non-technical and non-English speaking demographics. >> >> > > I think an important consideration is "can a user work around it in their > application", e.g. if we remove something from common middleware, they can > add it into their own middleware easily enough, if we change the core HTTP > processing pipeline, that's considerably more difficult for them, and such > changes shouldn't be made lightly. > > Alex > > >> To address a specific suggestion: >>> >>> On Saturday 14 June 2014 18:08:41 Marc Tamlyn wrote: >>> > >>> > That's not to say we should actively break support for old databases if >>> > they happen to work, but we should remove any conditional code we might >>> > have regarding them and we should not consider them when adding new >>> > features. >>> >>> "remove any conditional code regarding them" is exactly what I'd call >>> "actively >>> break support". What I want to do for "secondary support versions" is >>> - keep conditionals regarding them >>> - protect them from newer-version-only functionality (with no attempt to >>> add workarounds or client-side implementations) >>> - accept community patches to fix problems, as long as they don't put too >>> much of a burden on the code. >>> >>> I'm +0 on dropping Oracle9 support completely at this point, which means, >>> like Marc suggests, we just forget about it in code and declare it >>> unsupported >>> in docs. -0 on doing the same to Oracle 10. But it has to be a team >>> decision, >>> either way. >>> >> >> Agreed it's a team decision. >> >> But this actually raises a middle ground suggestion. There's a difference >> between "We're no longer testing for version X", "we *believe* we *may* >> have broken support for version X" and "We *know* we've actually broken >> support for version X." Following on from my earlier suggestion about >> raising a system check warning if an old DB version is detected, we can use >> language that indicates the extent of the damage: >> >> * if we're just taking a version out of our build pool, we say "version >> is no longer supported". >> >> * if adding a new feature requires removing code that added specific >> support for an old version, we change the message to add "and we have >> reason to believe that version will behave unexpectedly." >> >> The key here is that we don't just purge old version checks because we >> can; we only do so in the name of actual progress. I dont think we should >> purge a version check just because. However, we do have an obligation to >> adequately warn the user of problems we can foresee. >> >> >>> Also note: >>> >>> We claim to support MySql 5.0 and up. >>> >>> http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf >>> (page no. 19, which is the 21st page of the PDF): >>> MySql 5.0 EOL'd in Dec 2011 >>> MySql 5.1 in Dec 2013 >>> >>> We claim to support Postgres 8.4 and up -- 8.4 EOLs next month. >>> >>> Our docs still speak about SQLite 3.3.5. >>> >>> Besides database servers, there are also Python driver libraries to >>> consider; >>> we claim to require cx_Oracle>=4.3.1, but with cx_Oracle, only the latest >>> version is really supported -- so we should require 5.1.3 (fixing the doc >>> to require 5.1.3 for Python3 was already on my to-do list). I suppose >>> similar issues exist with the other backends. >>> >>> This discussion, as Aymeric noted, is really about all dependencies. >>> We discussed, and all but decided, to start using external dependencies >>> rather than vendoring libraries; but this means we can only do so for >>> libraries supported by projects with clear support policies. We need >>> to discuss the requirements for being a Django requirement. >> >> >> Agreed. Any time we depend on an external source, we introduce the >> possibility of problems, and in an ideal world, we'd be testing for it. In >> practice, I don't think we can do that. The best we can hope to do is some >> basic coverage of versions, and documentation of specific versions we know >> to be a problem. This may mean documenting the specific versions that a >> release has been tested with, and the versions that we believe to be >> working. >> >> Russ %-) >> >>> >>> Hope this isn't too messy to make sense, >>> >>> Shai. >>> >>> On Saturday 14 June 2014 18:08:41 Marc Tamlyn wrote: >>> > Not much to add, just that I agree with Tim and Aymeric. We cannot and >>> > should not claim to support database versions which are no longer >>> supported >>> > by their authors and do not receive security updates. >>> > >>> > That's not to say we should actively break support for old databases if >>> > they happen to work, but we should remove any conditional code we might >>> > have regarding them and we should not consider them when adding new >>> > features. >>> > >>> > Marc >>> > >>> > >>> > On 14 June 2014 15:55, Aymeric Augustin >>> > <aymeric.augus...@polytechnique.org> >>> > >>> > wrote: >>> > > On 14 juin 2014, at 14:40, Tim Graham <timogra...@gmail.com> wrote: >>> > > > My general proposal (for all databases) would be to drop support >>> for a >>> > > >>> > > database version in the Django release that follows its end-of-life >>> date. >>> > > >>> > > That's also my position. It applies to all dependencies of Django, >>> even >>> > > Python. >>> > > >>> > > I find it irresponsible to advertise support for software that no >>> longer >>> > > receives security updates. >>> > > >>> > > -- >>> > > Aymeric. >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > You received this message because you are subscribed to the Google >>> Groups >>> > > "Django developers" group. >>> > > To unsubscribe from this group and stop receiving emails from it, >>> send an >>> > > email to django-developers+unsubscr...@googlegroups.com. >>> > > To post to this group, send email to >>> django-developers@googlegroups.com. >>> > > Visit this group at http://groups.google.com/group/django-developers >>> . >>> > > To view this discussion on the web visit >>> > > >>> https://groups.google.com/d/msgid/django-developers/D89DCE98-6891-4EF5-9A >>> > > 04-34D3F8FC2BEE%40polytechnique.org . >>> > > For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-developers+unsubscr...@googlegroups.com. >>> To post to this group, send email to django-developers@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/201406150251.12616.shai%40platonix.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAJxq8497_tPwbnnft9hp0TB68UmXqqXFtnThtgidDFZhP%2BJc0A%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAJxq8497_tPwbnnft9hp0TB68UmXqqXFtnThtgidDFZhP%2BJc0A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAFRnB2WU83xD9YXcqpS%3DNLHH2PdNRZFr3z5CJydxTxOa70eLHw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFRnB2WU83xD9YXcqpS%3DNLHH2PdNRZFr3z5CJydxTxOa70eLHw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGdCwBtN3C7RB4CKJxjF%3DF-f1%3DGcanGThbjLw0bs_NhHk2O7Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
