Re: Time to drop support for Oracle < 11?

[Vladimir U.]

суббота, 14 июня 2014 г., 4:52:57 UTC+4 пользователь Tim Graham написал:
>
> Hi Shai and Oracle users,
>
> I came across a ticket (#11580 
> ) which proposes a fix that 
> works on Oracle > 11 but not for older versions along with the suggestion: 
> "Perhaps 
> it makes sense to abandon support for Oracle versions below 11g in Django 
> 1.6 or 1.7.".
>
> I looked up the support dates from Oracle:
>
> Release - GA Date - Premier Support Ends - Extended Support Ends
>
> 11.1 - Aug 2007 - Aug 2012 - Aug 2015
> 10.2 - Jul 2005 - Jul 2010 - Jul 2013
> 10.1 Jan 2004 - Jan 2009 - Jan 2012 
> 9.2 Jul 2002 - Jul 2007 - Jul 2010
>
>
> http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
>  
> 
>
> According to our docs 
> :
> Django supports Oracle Database Server  versions 
> 9i and higher. Oracle version 10g or later is required to use Django’s 
> regex and iregex query operators. 
>
> Is it time to drop support for versions of Oracle that are no longer 
> supported?
>


+1 for drop <11 ver.
It would be nice if newer Django versions work perfect with Oracle ver > 11 
than "not all features work" with all Oracle DB versions.

-- 
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/6f5d3060-b49e-4cc7-acc6-062743ecf7c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Reinout van Rees]

On 14-06-14 02:52, Tim Graham wrote:

11.1 - Aug 2007 - Aug 2012 - Aug 2015
10.2 - Jul 2005 - Jul 2010 - Jul 2013


To provide an additional data point: I checked with a colleague. We do a 
lot of business with governmental organizations in the Netherlands 
(mainly water boards). Most of them are on 11. With one or two still 
migrating from 10... :-)



Reinout

--
Reinout van Rees  http://reinout.vanrees.org/
rein...@vanrees.org   http://www.nelen-schuurmans.nl/
"Learning history by destroying artifacts is a time-honored atrocity"

--
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/lnmlbk%24qam%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Marc Tamlyn]

There will be a need for some gradiented support of Psql with
contrib.postgres. I think a sensible CI setup would be to run the full test
suite against 9.4 and the contrib.postgres test suite only against 9.1-9.3.
That would be my preferred compromise.

Marc
On 16 Jun 2014 01:24, "Russell Keith-Magee"  wrote:

>
> On Sun, Jun 15, 2014 at 11:49 PM, Hannu Krosing  wrote:
>
>>  On 06/14/2014 02:40 PM, Tim Graham wrote:
>>
>> It seems to weird to claim (even best-effort/community) support for a
>> database that is no longer supported by its authors. Also, you can always
>> use an older version of Django, right? I tend to think you're probably not
>> interested in the latest and greatest Django if you're using a really old
>> database. 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.
>>
>> Regarding testing, Oracle is currently not on CI, but Shai and I are
>> working to add support for 11 and 12. This would actually be the only
>> database where we have testing for multiple versions. For the other
>> databases we are using whatever version Ubuntu 12.04 ships with (PostgreSQL
>> 9.1.13, MySQL 5.5.37).
>>
>>
>> Heh, The "whatever version Ubuntu 12.04 ships with" test policy seems
>> kind of weird (especially if this is meant to go on forever :) )
>>
>
> It's an arbitrary version selection of an old(ish) commonly used Linux
> distribution.
>
> In an ideal world: Yes, we'd test against every major distro, and every
> major Postgres version installed on that distro, and so on; but we have
> limited resources (including the patience to make and configure build boxes
> as one of those resources :-)
>
> At some point in the future, long before EOL of Ubuntu 12.04, we'll
> probably upgrade the build boxes to 14.04. I'm guessing the introduction of
> Marc's PostgreSQL-specific features from his Kickstarter might be the
> stimulus for this.
>
>
>> According to http://www.postgresql.org/support/versioning/ PostgreSQL
>> 9.1 was released 2.5 years ago and is in the middle of its 5 year life
>> cycle which ends in September 2016.
>>
>> PostgreSQL 9.1 also lacks lots of newer stuff.
>>
>> Thanks to ubuntu/debian pg_createcluster  and friends it is actually easy
>> to run multiple versions of postgresql (I have everything from 8.4 to
>> latest 9.4 beta running in parallel on my laptop), so my suggestion would
>> be at least for postgresql to
>>
>> a) add pgdg repo to ubuntu (
>> http://www.postgresql.org/download/linux/ubuntu/ )
>> b) test with all versions supported by pgdg
>>
>
> Yes, this is possible; the question is whether this is a valuable use of
> our limited resources. I can only think of a handful of occasions in
> Django's 8 year public history where SQL-handling behaviour in PostgreSQL
> has changed in a way that required testing multiple versions - and most of
> those occasions were in the 7.X-8.X transition. Django's usage of SQL is
> fairly conservative; the areas where PostgreSQL is add features aren't the
> areas where Django treads, generally. As a result, there is a reduced
> imperative to test all these versions.
>
> This will of course change when we start supporting PostgreSQL-specific
> features, so we'll probably have to revisit this - but even then, I suspect
> testing an old version (e.g., 9.1) and a recent version (e.g., 9.4) will
> probably give us sufficient confidence that the build is working.
>
> Yours,
> Russ Magee %-)
>
>
>
> --
> 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/CAJxq849rV6pu_gX9JaCKOHxj%2BFU9p9U3ii%2BA54VHjF7WncT5Gw%40mail.gmail.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/CAMwjO1FL%2ByUGWVgOL0BrjZDOODs%3DDpmD8_FYV%2B2PNi0WwV4KFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Supporting and using EOL'd software (was Re: Time to drop support for Oracle < 11?)

[Shai Berger]

On Sunday 15 June 2014 10:59:17 Michael Manfre wrote:
> 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.
> 

I find this argument rather convincing. It blends well with several ideas I 
have floating around, of making the Oracle backend (and where applicable, 
others, of course) more easily extandable.

That said -- the Oracle backend is currently not extension-friendly enough for 
my tastes, and I don't think it is a good idea to make the changes I have in 
mind for 1.7; I haven't looked at other backends enough to make more general 
comments. And I'd really like to postpone any stripping-out of support until 
others can, indeed, implement it easily.

I also think we should, indeed, change the "advertising", already with 1.7, to 
say that support for Oracle < 11.2 is deprecated; after we've made it easy 
enough to extend, we can adopt Tim's rule of "dropped once EOL'd".

On Sunday 15 June 2014 12:34:04 Ian Kelly wrote, and I paraphrase: "there's 
not so much to win by dropping oracle 9/10". Perhaps this is true the 
currently-implemented feature-set, but I, for one, suspect we could make use 
of recursive CTEs (Oracle 11.2, PG9, Sql Server 2008 IIRC) and other new 
database features.

So, to summarize: I am +1 on changing docs to encourage users to use supported 
database servers; I am still +0,-0 on dropping the current Oracle 9,10 
(respectively) support in the code for 1.7; and +1 on dropping it in 1.8 after  
making it easy to support outside core.

Shai.

-- 
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/2938699.ldg0Pv1UR1%40deblack.
For more options, visit https://groups.google.com/d/optout.

Re: Supporting and using EOL'd software (was Re: Time to drop support for Oracle < 11?)

[Michael Manfre]

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  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  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 

Re: Supporting and using EOL'd software (was Re: Time to drop support for Oracle < 11?)

[Alex Gaynor]

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  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.
>>
>> 

Supporting and using EOL'd software (was Re: Time to drop support for Oracle < 11?)

[Russell Keith-Magee]

On Sun, Jun 15, 2014 at 7:51 AM, Shai Berger > 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.


> 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 

Re: Time to drop support for Oracle < 11?

[Russell Keith-Magee]

On Sat, Jun 14, 2014 at 10:55 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 14 juin 2014, at 14:40, Tim Graham  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.


Agreed. In times of old we also supported older versions of software
because they were distributed by RHEL. However, we now have a security
process that involves notification of RHEL staff (and others), and people
pay for RHEL so that they get security updates for specific versions of
software.

By way of providing adequate notification that old versions are dropping
off the list, introducing a system level warning if older versions of
databases (or any dependency) are found would be a good idea IMHO.

Russ %-)

-- 
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/CAJxq84-5y86-oUt0tvpXRKgHoxa-Yz6%3DOLozcdUDRe-%2B6otYrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Supporting and using EOL'd software (was Re: Time to drop support for Oracle < 11?)

[Shai Berger]

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.

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.

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.

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
> 
> 
> wrote:
> > On 14 juin 2014, at 14:40, Tim Graham  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 

Re: Time to drop support for Oracle < 11?

[Marc Tamlyn]

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 
wrote:

> On 14 juin 2014, at 14:40, Tim Graham  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-9A04-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/CAMwjO1G0bggWUxk0i4MqxrYLXwDW6TBxPGjPvhN6NAri1aNa_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Aymeric Augustin]

On 14 juin 2014, at 14:40, Tim Graham  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-9A04-34D3F8FC2BEE%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Tim Graham]

It seems to weird to claim (even best-effort/community) support for a 
database that is no longer supported by its authors. Also, you can always 
use an older version of Django, right? I tend to think you're probably not 
interested in the latest and greatest Django if you're using a really old 
database. 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.

Regarding testing, Oracle is currently not on CI, but Shai and I are 
working to add support for 11 and 12. This would actually be the only 
database where we have testing for multiple versions. For the other 
databases we are using whatever version Ubuntu 12.04 ships with (PostgreSQL 
9.1.13, MySQL 5.5.37).

On Friday, June 13, 2014 10:05:20 PM UTC-4, Ian wrote:
>
> On Fri, Jun 13, 2014 at 7:40 PM, Shai Berger  > wrote: 
> > Hi Tim and all, 
> > 
> > On Saturday 14 June 2014 03:52:57 Tim Graham wrote: 
> >> 
> >> Release - GA Date - Premier Support Ends - Extended Support Ends 
> >> 
> >> 11.1 - Aug 2007 - Aug 2012 - Aug 2015 
> >> 10.2 - Jul 2005 - Jul 2010 - Jul 2013 
> >> 10.1 Jan 2004 - Jan 2009 - Jan 2012 
> >> 9.2 Jul 2002 - Jul 2007 - Jul 2010 
> >> 
> >> According to our docs 
> >> : 
> >> Django supports Oracle Database Server  
> versions 9i 
> >> and higher. Oracle version 10g or later is required to use Django's 
> regex 
> >> and iregex query operators. 
> >> 
> >> Is it time to drop support for versions of Oracle that are no longer 
> >> supported? 
> > 
> > Heh. I tried this one myself, 2.5 years ago: 
> > 
> https://groups.google.com/d/msg/django-developers/SQ0Pltt_f0M/-h0jvJc5p1cJ 
> > 
> > Unlike ikelly at that time, I'm not aware of people still using Oracle 8 
> or 9, 
> > but reports about Oracle 10 were still received not too long ago (e.g. 
> > https://code.djangoproject.com/ticket/20292 includes a report by an 
> Oracle 10 
> > user from a year ago). I don't want to pull rugs from under these 
> people's 
> > feet, if they are still out there. 
>
> I'm pretty much out of the Oracle fold at this point, so I don't know 
> either how common these installations still are.  A stackoverflow 
> search for "[oracle9i]" shows that several new questions per month are 
> still being asked there. "[oracle9i] [django]" is looking pretty 
> empty, though. 
>
> My only comment at this point is that if support is to be dropped, 
> #11580 doesn't make a particularly strong case for it since running an 
> icontains query on a TextField isn't going to scale well and probably 
> isn't a good idea to start with. 
>

-- 
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/abfb2f24-ee06-4c0c-ab70-50530eb7fc83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Ian Kelly]

On Fri, Jun 13, 2014 at 7:40 PM, Shai Berger  wrote:
> Hi Tim and all,
>
> On Saturday 14 June 2014 03:52:57 Tim Graham wrote:
>>
>> Release - GA Date - Premier Support Ends - Extended Support Ends
>>
>> 11.1 - Aug 2007 - Aug 2012 - Aug 2015
>> 10.2 - Jul 2005 - Jul 2010 - Jul 2013
>> 10.1 Jan 2004 - Jan 2009 - Jan 2012
>> 9.2 Jul 2002 - Jul 2007 - Jul 2010
>>
>> According to our docs
>> :
>> Django supports Oracle Database Server  versions 9i
>> and higher. Oracle version 10g or later is required to use Django's regex
>> and iregex query operators.
>>
>> Is it time to drop support for versions of Oracle that are no longer
>> supported?
>
> Heh. I tried this one myself, 2.5 years ago:
> https://groups.google.com/d/msg/django-developers/SQ0Pltt_f0M/-h0jvJc5p1cJ
>
> Unlike ikelly at that time, I'm not aware of people still using Oracle 8 or 9,
> but reports about Oracle 10 were still received not too long ago (e.g.
> https://code.djangoproject.com/ticket/20292 includes a report by an Oracle 10
> user from a year ago). I don't want to pull rugs from under these people's
> feet, if they are still out there.

I'm pretty much out of the Oracle fold at this point, so I don't know
either how common these installations still are.  A stackoverflow
search for "[oracle9i]" shows that several new questions per month are
still being asked there. "[oracle9i] [django]" is looking pretty
empty, though.

My only comment at this point is that if support is to be dropped,
#11580 doesn't make a particularly strong case for it since running an
icontains query on a TextField isn't going to scale well and probably
isn't a good idea to start with.

-- 
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/CALwzid%3DWHHHqe-a0UcR1EX8zZx4VtXicPFjNHVL91AHqGXUyJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Josh Smeaton]

Personally we use oracle 11g (with a plan to move to 12c within the next 
year), but it wasn't that long ago that we were still using 10g. We're a 
smaller company that is able to upgrade our database without significant 
impact, but I'm betting (and guessing..) the vast majority of oracle users 
aren't.

I think Shai raises a good point - testing against the various versions of 
Oracle is very difficult. Is there anyway we can fix that? What version of 
oracle is used by CI for testing? And is there a way we can get some 
different versions of oracle working with the CI? Further, how are the 
various versions of other database backends validated? If we can apply the 
same or similar methods I think we'll be able to be in a better position to 
claim support for particular versions.

As for the suggestion of "if ora_version >= 11" - I think that'd be a fine 
interim solution, but it doesn't really address the problem.

Josh

On Saturday, 14 June 2014 11:40:57 UTC+10, Shai Berger wrote:
>
> Hi Tim and all, 
>
> On Saturday 14 June 2014 03:52:57 Tim Graham wrote: 
> > 
> > Release - GA Date - Premier Support Ends - Extended Support Ends 
> > 
> > 11.1 - Aug 2007 - Aug 2012 - Aug 2015 
> > 10.2 - Jul 2005 - Jul 2010 - Jul 2013 
> > 10.1 Jan 2004 - Jan 2009 - Jan 2012 
> > 9.2 Jul 2002 - Jul 2007 - Jul 2010 
> > 
> > According to our docs 
> > : 
> > Django supports Oracle Database Server  
> versions 9i 
> > and higher. Oracle version 10g or later is required to use Django’s 
> regex 
> > and iregex query operators. 
> > 
> > Is it time to drop support for versions of Oracle that are no longer 
> > supported? 
>
> Heh. I tried this one myself, 2.5 years ago: 
> https://groups.google.com/d/msg/django-developers/SQ0Pltt_f0M/-h0jvJc5p1cJ 
>
> Unlike ikelly at that time, I'm not aware of people still using Oracle 8 
> or 9, 
> but reports about Oracle 10 were still received not too long ago (e.g. 
> https://code.djangoproject.com/ticket/20292 includes a report by an 
> Oracle 10 
> user from a year ago). I don't want to pull rugs from under these people's 
> feet, if they are still out there. 
>
> On the other hand, neither me personally nor the Django project, as far as 
> I'm 
> aware, have access to any of the versions you listed (not even 11.1); we 
> can't 
> really commit to supporting them when we can't test against them. 
>
> So the approach I'd take is not to drop support altogether, but declare 
> these 
> versions supported on a "best effort and community support" basis -- which 
> means a change in documentation, but not really in code. As a matter of 
> policy, I wouldn't knowingly make a change which breaks Oracle 10 support, 
> but 
> I can't detect or solve such problems (if they crop up) without actual 
> users' 
> help. 
>
> I'll want to hold this position, and add improvements under "if 
> ora_version>=11", until it becomes unwieldly, or a longer time has passed 
> since the last Oracle10 user report. I'd consider it for 1.8, but not 
> sooner. 
>
> Shai. 
>

-- 
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/876d6e1f-ded3-4ffb-946d-433e4c8d5bc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Time to drop support for Oracle < 11?

[Shai Berger]

Hi Tim and all,

On Saturday 14 June 2014 03:52:57 Tim Graham wrote:
> 
> Release - GA Date - Premier Support Ends - Extended Support Ends
> 
> 11.1 - Aug 2007 - Aug 2012 - Aug 2015
> 10.2 - Jul 2005 - Jul 2010 - Jul 2013
> 10.1 Jan 2004 - Jan 2009 - Jan 2012
> 9.2 Jul 2002 - Jul 2007 - Jul 2010
> 
> According to our docs
> :
> Django supports Oracle Database Server  versions 9i
> and higher. Oracle version 10g or later is required to use Django's regex
> and iregex query operators.
> 
> Is it time to drop support for versions of Oracle that are no longer
> supported?

Heh. I tried this one myself, 2.5 years ago: 
https://groups.google.com/d/msg/django-developers/SQ0Pltt_f0M/-h0jvJc5p1cJ

Unlike ikelly at that time, I'm not aware of people still using Oracle 8 or 9, 
but reports about Oracle 10 were still received not too long ago (e.g. 
https://code.djangoproject.com/ticket/20292 includes a report by an Oracle 10 
user from a year ago). I don't want to pull rugs from under these people's 
feet, if they are still out there.

On the other hand, neither me personally nor the Django project, as far as I'm 
aware, have access to any of the versions you listed (not even 11.1); we can't 
really commit to supporting them when we can't test against them.

So the approach I'd take is not to drop support altogether, but declare these 
versions supported on a "best effort and community support" basis -- which 
means a change in documentation, but not really in code. As a matter of 
policy, I wouldn't knowingly make a change which breaks Oracle 10 support, but 
I can't detect or solve such problems (if they crop up) without actual users' 
help.

I'll want to hold this position, and add improvements under "if 
ora_version>=11", until it becomes unwieldly, or a longer time has passed 
since the last Oracle10 user report. I'd consider it for 1.8, but not sooner.

Shai.

-- 
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/201406140440.14880.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.