Do I understand the support schedule correctly?

[Steve Bergman]

I'm considering using Django for 2 projects. An LFS shop and a site
which will use Pinax. Both high profile Django apps. At this time, the
latest supported Django version for both is 1.3.3. If I understand
correctly, the 1.3 branch of Django will no longer get security
updates after 1.5 releases. The nominal release cycle for Django
appears to be 9 months. And in practice it looks more like 1 year. So
Django 1.5 should be out sometime between December and March. If I
deploy in a month, that means a forced upgrade on both framework and
apps in just 3 to 6 months from launch. And that's assuming that the
apps have versions which support Django 1.4 by that time.
Obviously, I'm missing something here, since no sane organization
would accept such a situation. (It would certainly be a deal-breaker
for us.) But I'm not sure what it is that I'm missing.

[creecode]

Hello Steve,

On Saturday, August 4, 2012 9:24:27 AM UTC-7, Steve Bergman wrote:

that means a forced upgrade on both framework and
apps

Why a forced upgrade?  Just use what you installed to get your projects up and running until such time as as conditions are comfortable for you to upgrade.

The key factor for your situation is going to be how quickly the apps you're using with Django follow the updates to Django.  You don't have to run the latest of everything to get some work done.

Toodle-looooooooo............

creecode

[Russell Keith-Magee]

From Django's perspective, you've correctly understood the situation.
We officially support a development release, a stable release, and a
security release (currently 1.5 in preparation, 1.4 and 1.3
respectively). Our releases come on a 9-12 month cycle, which means
that if you were to move to the current stable release (1.4) right
now, you could reasonably expect to receive security updates for the
next 18 months or so (i.e., until the release of Django 1.6).

The problem you've got isn't with Django, it's with the downstream
tools you want to use *with* Django. I can't speak with authority for
Pinax or LFS, but if they're reporting that they're only officially
supporting Django 1.3, then yes; you'd be deploying onto 16 month old
code right now, and you will have a problem when Django 1.5 comes out
in a few months. This would be worth taking up with the Pinax and LFS
development teams; Django 1.4 came out almost 4 months ago -- if the
maintainers of these projects haven't made a statement about Django
1.4 support, that's slightly concerning.

However, I would say that Django itself has a very strong backwards
compatibility policy. I recently updated a sizeable codebase from 1.3
to 1.4, and the only problems I encountered were with the test suite
-- ironically, minor changes to Django's test runner in 1.4 revealed
some test failures that were being silenced by 1.3's test runner.
Chances are, the issue with Pinax and LFS is entirely one of
documentation -- i.e., that the projects in question simply haven't
updated their documentation, not that there is a problem preventing
them from moving onto future releases.

I would also add that when we make a security release, we provide full
disclosure of the issue, including a description of the problem and a
patch for our supported versions. Often, this patch is identical
between versions, so it may be possible for you to be running a very
old version of Django an manually apply any security patches
(effectively doing your own security release for an officially
unsupported Django version).

Yours,
Russ Magee %-)

[Mike Dewhirst]

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?

I know a couple of large organisations who simply won't consider non-LTS
open source kit.

Mike

[Russell Keith-Magee]

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?

Yours,
Russ Magee %-)

[Mike Dewhirst]

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 %-)
>

[Thomas Lockhart]

> 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?

Two years to be able to stick with a single version? Just fine imho.

A few points you have probably heard before:

Django is just one layer of the stack. Extending support because other layers don't have a critical mass or a release cycle to provide new versions may not be a problem that Django should be expected to solve.

Growing the number of supported versions competes with evolving and keeping fresh. And evolution is critical for attracting and keeping contributing developers; LTS is not the interesting place to be in the long run.

Diverting (free) developer resources to keeping "large organizations" happy may be at odds with the benefits and tradeoffs of an open source project. If large organizations want to pony up developers or money then I'll bet they can keep an LTS release going indefinitely so there isn't really a conflict there. In my experience those organizations will provide those resources if they feel the added value is important to them.

If independent or contract developers are hoping to use Django to deliver software to other organizations then the support cycle needs to match the customers' needs. But that is between the developer and the customer to work out the best set of tools for the job.

If an organization won't consider a tool stack because it does not have an LTS plan matching their requirements, then I know of at least one organization which should not use that tool stack. They are making the tradeoffs, and can choose the best solution for their needs.

But in my experience, when someone locks onto a version for a substantial period of time, they will end up orphaning the product or they have (perhaps unwittingly) deferred the modest pain in keeping fresh on versions to feeling a large amount of pain later on when they upgrade. I prefer the pain to arrive in smaller doses.

Thanks for asking ;)

������������������������� - Tom