Hi, On Thu, Nov 05, 2015 at 06:58:42PM +0100, Johannes Berg wrote: > On Thu, 2015-11-05 at 16:00 +0000, Stephen Finucane wrote: > > Django 1.6 is no longer supported, neither with feature bugfixes nor > > security fixes. Additionally, Django 1.6 does not support the use of > > Django Migrations, necessitating the continued use of manual SQL > > migration files. Drop support for Django 1.6 thus encouraging users > > to move to Django 1.7 or, ideally, Long Term Support (LTS) release > > 1.8. > > > > RHEL (or really EPEL7) has Django 1.6.11 [1] > > This is what's going to be installed on kernel.org, so this would be > really sad for us using their instance, since we couldn't ask them to > update patchwork beyond this change. > > Any chance you could reconsider?
A possible solution: is there any chance to consider using a python vritualenv for the patchwork instance? that's a great way to decouple once and for all patchwork's requirements from the system django and for other django applications that may run on the same server (which, say would only work with django 1.4, not theoritical, I've unfortunately seen that case). There is always the question of how to then distribute security fixes. Distributions backport security fixes to older, unsupported, versions of django. Of course, going outside of the distribution means handling dependency updates yourself. FWIW and for the patchwork instances I manage, I use virtualenv, stick to the django LTS version (1.8 at the moment), and make sure there's a way to do continuously deploy the latest dependencies (CI system + fabric deployment (http://www.fabfile.org/)). Once automated, the human cost of this solution is small (I still do the final "go" by hand, just to double check things). HTH, -- Damien _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
