On Sunday 14 June 2015 00:13:33 Mark Nunberg wrote:
> Hi folks!
>
> I apologize in advance if this is the wrong venue for this discussion
>
> I'm trying to determine the best means by which I might be able to add
> Couchbase (http://www.couchbase.com) support to Django. I've come across
> somethi
In non-code work, the discussions about the future release schedule
continue in the "1.9 release planning" thread. I hope we can finalize that
within the next week or so.
Report for week ending June 13, 2015:
Triaged
---
https://code.djangoproject.com/ticket/24948 - BMP Image File trea
There's nothing in the way of official documentation about writing
third-party database backends. I guess the best approach would be to look
through the source code of database engines in Django as well as the
projects you mentioned and learn from that. If we can add any hooks to
Django to help
I agree there are many ways to accomplishing things in the admin, but
cleaning that up and continuing BC is a completely other ticket /
implementation (it looks like a good Sumer of Code project similar to the
Meta API recently completed). Since the ticket was marked as accepted,
I'll double c
Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs
reference Django 1.9. I'm not enthusiastic about updating all that.
On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
>
>
> > On Jun 13, 2015, at 20:43, Tim Graham >
> wrote:
> >
> > I don't have a strong opini
> On Jun 13, 2015, at 20:43, Tim Graham wrote:
>
> I don't have a strong opinion either way on semver, but I think it's a bit
> late to rebrand 1.9 as 2.0 considering we've release code and docs with
> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? We
> could plan
Django 1.8 was the last version to support Python 3.2, which has its
security updates end February 2016. That means Python 3.2 users can
continue getting Django security updates for about 2 years after Python
security updates end. I am wondering if we should instead try to better
align the end
Hi folks!
I apologize in advance if this is the wrong venue for this discussion
I'm trying to determine the best means by which I might be able to add
Couchbase (http://www.couchbase.com) support to Django. I've come across
something called "django-nonrel" - it seems to have scarce documentatio
I don't have a strong opinion either way on semver, but I think it's a bit
late to rebrand 1.9 as 2.0 considering we've release code and docs with
reference to "RemovedInDjango19Warning". Do you have any thoughts on that?
We could plan the change for after the next LTS (2.1 -> 3.0) to correspond
I ended up abstracting our usage of inspect.getargspec() into some utility
methods in a django.utils.inspect module. Each method has a separate branch
for Python 2 and Python 3. It's not ideal, but I think it's preferable to
adding a short-lived dependency or vendored copy, considering that drop
Quoting semver.org:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
We are only breaking the f
I'm happy to give it a try if there's consensus that it might help. On the
other hand, this doesn't account for the inevitable backwards incompatible
changes that come along. For example, someone in the survey said "Django
1.7 is a hard change for clients and it should have been 2.0 so that they
I think Collin's proposal can match semver without additional overhead when LTS
are the final minor releases of any given major branch.
1.8 LTS
2.0 (Drop features from 1.7)
2.1 (Drop features from 1.8 LTS)
2.2 LTS
3.0 (Drop features from 2.0, 2.1)
3.1 (Drop features from 2.2 LTS)
3.2 LTS
That wa
13 matches
Mail list logo
