On 7/08/2012 11:15am, Russell Keith-Magee wrote:
On Tue, Aug 7, 2012 at 8:40 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
Russell
This might be slightly off-thread. Since 1.5 will be Python 3, would you
consider making 1.4 a long-term-support version?
Django 1.5 will be the first Django release to officially support
Python 3, but it will still support Python 2. We're not going to go
cold-turkey on Python 2 -- we'll be supporting Python 2 for a while
yet.
I know a couple of large organisations who simply won't consider non-LTS
open source kit.
The core team has talked about this sort of approach in the past --
usually in the context of moving to a faster release cycle (e.g.,
release every three months, but nominate a LTS release every 18 months
or so). However, those discussions usually stall on the problem of
actually doing a faster release, which historically, we haven't been
good at doing.
I'd be interested in hearing other opinions about this. Out there in
the "real world" (™), how long does Long Term Support have to be in
order to be practically useful?
I think Django is mature "infrastructure" and needs to be appreciated as
such.
The current release cycle you previously described is pretty good and
easy to understand but ... it doesn't *sound* like an infrastructure
release cycle.
The Canonical Ubuntu LTS server release cycle [1] seems quite good. As
everyone knows, they support the LTS version for five years but release
another one every two years. That represents a significant support
workload for them which they can justify because of their commercial
support business.
The nice thing about it is everyone can plan their migrations for the
foreseeable future. That includes end-users in business who can perhaps
target the third year to upgrade to the next LTS or if push comes to
shove have the luxury of keeping their infrastructure migration dollars
in their pockets for another year.
Django isn't quite so commercial as Canonical. Hence the extra workload
of backporting security patches as long as they do might be prohibitive.
Perhaps a minimal workload solution is to just slow down the existing
release cycle a little and call each second release a LTS version ...
- - - - Long 2012 - 2016
- - Short 2013 - 2015
- - - - L 2014 - 2018
- - S 2015 - 2017
- - - - L 2016 - 2020
- - S 2017 - 2029
All development takes place in Shorts and all Longs simply get security
patches. I reckon all deployments would be Longs and all migrations
planned for the third year.
Mike
[1]
http://www.ubuntu.com/business/server/overview#a-release-schedule-you-can-depend-on
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
