o publish different releases for
> different versions of django.
>
> Dan
>
> On 25 November 2016 at 10:01, Vlastimil Zíma > wrote:
>
>> I don't think separate migrations would make the problem any better, that
>> looks just like more complicated implementation of
ly when I see a use case for multiple
> Django version support it's for reusable apps, which shouldn't contain a
> custom user model.
>
> https://docs.djangoproject.com/en/stable/topics/auth/customizing/#reusable-apps-and-auth-user-model
>
> On Thursday, November 24, 2016 at
lp.
>
> On Tuesday, October 18, 2016 at 7:12:02 AM UTC-4, Vlastimil Zíma wrote:
>>
>> Hi everyone,
>>
>> we are trying in our application to support multiple Django versions,
>> specifically 1.7 to 1.9. But we encountered a problem with
>> `User.last_l
> based on the Django version, conditionally adding operations in migrations
> with some django.VERSION checks may help.
>
> On Tuesday, October 18, 2016 at 7:12:02 AM UTC-4, Vlastimil Zíma wrote:
>>
>> Hi everyone,
>>
>> we are trying in our application to sup
Hi everyone,
we are trying in our application to support multiple Django versions,
specifically 1.7 to 1.9. But we encountered a problem with
`User.last_login` field. We use custom User model based on
`AbstractBaseUser` as specified by the documentation. Everything was fine
in Django 1.7, but
Hello,
I am using django 1.1 and I discovered this problem:
I have models like these
---
class Place(model.Models)
...
class Restaurant(Place)
...
class Bar(Place)
...
---
the primary key counters for Restaurant and Bar classes are separate
6 matches
Mail list logo
