<div dir="ltr">I found the release note from django that talks about not supporting postgres 8.4 in django 1.8: <a href="https://docs.djangoproject.com/en/1.9/releases/1.8/#support-for-postgresql-versions-older-than-9-0">https://docs.djangoproject.com/en/1.9/releases/1.8/#support-for-postgresql-versions-older-than-9-0</a><div><br></div><div>Are you aware of any actual incompatibility? Or are they not supporting postgres before 9.0, because upstream postgres doesn't support it?</div><div><br></div><div>This certainly isn't ideal, but I wonder if django 1.8 would happily work on postgres 8.4, and we'd just be on our own if stuff goes wrong. And obviously we couldn't use any new postgres-specific features in that case. Or maybe there actually are backward-incompatible API changes in 9.0?</div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 28, 2016 at 12:52 PM, Patrick Creech <span dir="ltr"><<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Team,<br>
<br>
So, it appears the 'Which verson of postgresql' to support is a little more nuanced than we<br>
initially hoped.  Primarily, it locks us into what version of django we are using.<br>
<br>
Currently, the plan is to support whatever postgresql is provided by default in EL6 (v8.4).  The<br>
feedback we have received from some stakeholders is that is the path they have chosen, and taking<br>
them and Sattelite into account, it might be nice for them not to have to explain why you need two<br>
different versions of the same database installed.<br>
<br>
On top of that, some of our own userbase might be installing pulp in a datacenter in which they have<br>
already had a significant investment put into their own PostgreSQL installation.  These people would<br>
probably like to use that database server instead of having to stand up another one.  (Setting up a<br>
database server following compliance and HA guidelines is a huge investment, and they will probably<br>
want to maximize the benefit they get for that investment).  Allowing the maximum compatibilty for<br>
user scenarios will be a huge benefit for adoption, in my opinion[0].<br>
<br>
Which leads me into this next topic, which is Django version support.  With the decision to support<br>
PostgreSQL 8.4 (default in EL6), We effectively lower our maximum version of Django support to 1.7.<br>
 Take also into account that the default python on EL6 is 2.6, we effectively lower the maximum<br>
version again to 1.6.  The state of using SCL Python 2.7 will probably dictate our maximum version<br>
here for EL6.<br>
<br>
Another +1 to possibly using Django 1.7 with SCL Python 2.7 is that django maintains y+1<br>
compatibility, allowing us to potentially use Django 1.8[1] in envirionments that provide postgresql<br>
9.0 or higher.  (EL7 has 9.2 by default)  This might also have other impacts though, which have yet<br>
to be fully researched.<br>
<br>
With this being said, we are still open to questions/thoughts/concerns on these topics, and would<br>
like to hear your feedback if you have any.<br>
<br>
Thanks,<br>
Patrick<br>
<br>
[0]:<br>
And, if we pay attention to how we use django models, we might be able to say we run on multiple<br>
databases, and support whatever is supported by that Django version, thereby maximising our database<br>
compatiblity.<br>
<br>
[1]:<br>
Why would we be interested in Django 1.8?  Because Django 1.8 is an LTS release.</div></div><br>_______________________________________________<br>
Pulp-list mailing list<br>
<a href="mailto:Pulp-list@redhat.com">Pulp-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-list</a><br></blockquote></div><br></div>