Transcript: Django Versions
Hello and welcome to another episode of Django Chat. Today we're going to talk about versioning
in Django. 2.2 just came out which is a long-term support release so we're going to dive into what
that means and how to understand versions in Django. Hi Carlton, how you doing? Hi Will, I'm doing very
well. So you are the Django Fellow, you are as much as anyone responsible for the releases of Django,
right yes yes it falls upon me so one of the key points about the fellow program is that we handle
the releases um and so we do those monthly normally and yeah that that's a key role can
you talk just briefly about the core the levels of involvement right the core django and uh developers
people who can do commits and how that all kind of comes together for a major release like 2.2
okay well so most of the commits now are done by the fellows which um up until recently was tim
graham he's just sat down and now it's um myself and manis who do the uh the current changa fellows
and and you mean approving approving what gets in well yeah but also anybody can help approve so
you know if you if you want to come and review a pull request then please do um there's a check
patch review checklist and that would be amazing event if you want to come in we'll talk in another
episode about contributing more to um but then once all the commits are in maris and i are
responsible for rolling the release and putting it up on PyPI and making it available to you.
Got it. Got it. So let's talk about, so 2.2, this comes after 2.1 and 3.0 is coming out later this
year in December. Can you talk a little bit about what is, you know, what makes something a major
release? And then we can talk about, you know, why the switch to starting with 3.0 and 3.1 and all
the rest of it okay so each version of django has a main a period of nine months where it's in
mainstream support and so 2.2 is now the current version and we've just finished with 2.1 and
before that 2.0 and then before that 1.11 and the major versions um between one point something
two point something three point something is there'll be a long-term support for each major
version and that so is what beyond the initial nine months where a version gets met um is in
mainstream support it also gets another nine months of extended support where it gets security
fixes and any data loss bugs get backported the long-term support release gets a whole like 18
a whole another two years i think or how about right well well within that so so 2.1 which we're
just coming off of so 2.1 came out and then there's also there'll be you know periodically
2.1, .1, .2.
These are the smaller. What's the technical term?
Those are generally security updates, right?
Well, okay, so when the new version
comes out, for the first nine months, it's in
mainstream support, and it will basically get
a release every month.
I mean, unless there are no changes, but there will
be changes. And at that point, it gets
bug fixes. Any bug fixes that come
in within that first nine months
get included
in the current
version, whichever is the current version.
that's what mainstream support means right so the so april april 2.2.0 and then probably in may
there'll be 2.2.1 which will be the bug fixes that have come up yes and that process will continue
for the nine months for nine months yeah and then once that version reaches the end of mainstream
support it goes into extended support and that after that there will only be a release if there's
a security issue or if there's a data loss bug and this gets into long-term support releases right
yeah right so the long-term support releases last for the whole like basically four releases it's
it's it's the whole of the 2.0 cycle 2.2 will be there until 4.0 basically right in the same way
that 1.11 was the previous long-term support release so 1.11 has continued to be updated for
2.0 2.1 yeah i think that's got another nine months to go even now yeah right so yeah so and
the key point is that you the long-term support they're not getting bug fixes they're only getting
once they're outside of mainstream support they're just like all the other versions they get nine
months of the latest bug fixes getting back getting put in but then they'll only get a backport of
another fix if it's a data loss bug or security bug and they give a bit more stability if you're
If you're running an application where you can't guarantee that you'll be able to keep
up with the latest version, then they give you the stability and the security to know
that for the whole life of that major series, your version will be supported.
2.2 will be current all the way through till the next long-term support at the end of the
3.0 series, or the 3.x series.
So you can stay on that for two years or three years.
Which I think a lot of companies do.
Yeah.
And yet we've discussed this, you know, privately.
It's worthwhile to stay up to date,
not just stay on the long-term support release,
but to, and so, you know, we've talked about, you know,
what are the highlights for the reasoning for that, right?
Because the company is sitting there saying,
this takes time, I don't have time.
Okay, so back in the day, maybe,
updating between Django versions was a serious thing.
There were quite a lot of breaking changes
and it was difficult to update.
These days, we're much more conservative.
And this is one of the great things about Django,
is it being, because it's a mature framework,
people sometimes think that that means it's boring.
No, that means it's really exciting.
Yeah, that means it won't break on you.
It won't break on you.
So we are really careful about not introducing breaking changes.
And if we do, they're well-documented, and they're small,
and there's a deprecation policy.
And what does that mean?
It means that if we're going to get rid of a feature,
it won't be got rid of immediately.
It will be in the version which, so say we introduce a deprecation now in 2.2, it will
be pending deprecation in 2.2, it will be deprecated in 3.0, and it will only be removed
in...
Right.
And we're going to link to this in the notes, there is a way to run Python and see these
deprecation warnings before it fully breaks i mean because this is a point you know there's
a lot of people are still on django 1.5 and so if 2.2 comes out certainly i've done this before
you know you say okay i'll just update to 2.2 and fix everything that's broken but as you have
educated me that is decidedly not the way to do it because if you go uh you know 1.6 with flags
and correct things then 1.7 right this is the recommended way to yeah i mean to get up to get
all the way from 1.5 it's you've got about you've got to dedicate some time but let's say you're on
1.11 yeah 1.11 that's more real you're on a supported version if you're not on a supported
version well okay uh there's time but the general policy is the same it's just going to take you
longer so from 1.11 run with the the deprecation warnings enabled so um a pending deprecation
warning won't show by default. So you have to run it with this W flag. You can either run it with D
for deprecations or to get all warnings to show. So this would be like run, so Python manage.py
run server. Yeah. Okay. So instead of running manage.py run server, you have to run Python
with the W flag. So WD for deprecations and then manage.py run server. So you have to invoke
Python explicitly. And again, we'll link to that so people can see that. But then it will then show
the deprecation warnings and so on the version that you're on run it with the warning flags
enabled then fix those deprecation warnings then upgrade not from 1.11 to 2.2 but 1.11 well
okay so in theory right in theory you can upgrade from one lts support to the next lts support
without having to jump on go on all the hoops that's the idea between them behind them but
whether or not you can practically speaking you're better off to go you're better off to
go to the to the minor next minor version so 2.0 fine run again with the warning flags enabled fix
any warnings 2.1 same again yeah i think i think these deprecation warning flags are a very
underutilized feature right and the key point is if you do this and this is where django is so
exciting but if you could do this process once every nine months you can allocate a day or
whatever to running installing the new version turning up turning on the flags making sure it's
it's all fixed installing the new versions grab a coffee read the release notes because there
are copious release notes yeah which we'll also link to for every version yep right and they
they give you all the breaking changes and you know and the upgrade process is actually these
days very smooth yeah it's changed it's it's a lot smoother than it was and and you also you know
you of course you have tests in your project right so you can run your tests and if you've got yeah
if you've got ci then just or you know even if you haven't got ci you've just got unit tested
brilliant you can create a clone of your virtual environment you can install the latest version you
can even install django master from kip and then you can run the test suite and see what's breaking
and if things are breaking before a release comes out so we've just finished we've just released 2.2
but there's there's an alpha release there's a beta release there's a release candidate if you
can install those beforehand and run your test suite and let us know what's breaking then you
we will fix those those breakages before yeah this is really important for the community to
yeah to do the pre-release versions yeah especially if you've got ci there's no reason
why not use talks create an environment that installs the development version or the release
candidate version run your test let us know if something broke that wasn't meant yeah and we're
going to do a whole separate episode on testing and continuous integration and you know talks
there's a whole number of other services um but the takeaway is you should have this yeah we'll
cover we'll cover how you can do it i mean this is something i'm spending quite a bit of time in
my new book uh django for professionals talking about how to do this because it's not always well
documented but uh you know if you're thinking about joining a company or a project and they
do not have a continuous integration testing that's a big big warning flag it just is crazy
once you know a little bit about django and web frameworks not to be using one or anything like
it's not just Django it's it's everything like yeah untested code is broken by design is the
quote right yeah but you know for the beginner intermediate developers or people who've done
solo projects um just we're mentioning this for you yeah I mean you will see it you will see it
and you will see crazy things you in the real world um but for me you've got to test the code
somehow right so you can either open up your browser and load up the page and click through
manually in which case every time you come to test it you've got to go through those manual steps
or you can take the time to write a unit test of some kind you know be it using a browser driving
like selenium or something like selenium or something like that or just a unit testing
in python code but if you take that time then you can run that test that test automatically
every time you make a code change rather than having to do it manually you've got to test it
either way so you might as well yeah and you have to test it for yourself on a project once you get
beyond a very basic stage and then when you're on a team you absolutely have to you will just go
crazy without the test yeah and some and when you're writing code as well i mean people talk
about test driven development you know some test driving is great but for me something quite often
very often i don't know how a code is going to behave on the same way i so one way of one way
of working out how it's going to behave is to write a unit test and then you know i can some
You can even put a breakpoint in the unit test and you can say, ah, this is the state at that point.
Right. I don't think it's helpful. Well, there's a whole bunch of talks on this.
I mean, David Hennemeyer Hansen, I think, is the most public in being against extreme test-driven development.
I think the key is whatever works for you. Sometimes I'll do the test first.
Probably generally speaking, I write the test after, but immediately after.
But it sort of doesn't really matter.
The tricky thing is when you're learning Django is it's hard to write a test when you have no idea what you're doing.
So I think especially, you know, formal test-driven development where you write the test first, that presupposes you know where you're going.
And so, you know, if someone's a beginner or an intermediate, I would not worry about having trouble doing test-driven development.
because it's just something that it's more,
I think it's more of an expert level thing.
When you're beginner, intermediate,
it's much more appropriate to write the test
after you've gotten the code working, I would say.
Yeah, and like, yeah.
But you'll hear different things,
but I guess don't beat yourself up about it.
I mean, I have trouble doing TDD.
My brain just doesn't quite work like that.
On occasions, as you mentioned,
sometimes writing the test
will help me think about the problem,
but I think people who are really
into test-driven development talk about it,
And people who just do normal tests don't talk about it as much.
So there's a little bit of an imbalance there.
Yeah, I think so.
What would I say?
I'd say even if you're a beginner, use the Django test client.
And just write a test for the happy case.
Yeah, I hit the URL and it loaded.
Happy path programming, yep.
But it loaded and it gave me 200 response.
And in the response was, you know, hello world, whatever you put in your HTML page.
And what that gives you then is at least a regression test.
So you can run something and if something broke, then that won't work anymore.
Yeah, well, and since we're, you know, since we're talking about tests, just at least for
me, I typically will start with, yeah, does it do I get a 200 response?
Do you know, check the template?
Do I use am I using the correct template?
Does that you know, if the template has homepage in it, I'll test something that's in the template
that should be there, then you can test the views, you know, so you can go through you
test the templates test the views the urls test the models it yeah it's helpful we'll do a whole
thing on it yeah and say you added i don't know a method to your model property to your model that
calculates something or just write a nice a test for that did it work well there's two ways of
checking did it work you can open up the shell and call it by hand or you can write a test that
does the same thing right yeah it's actually a little bit lazier it's lazier to write the test
because rather than having to keep manually doing it yeah exactly so all right well let's let's move
on slightly though um we oh yes so django 3.0 so that's coming out so this year there's two
major releases 3.0 comes out in december and maybe i think if you can talk about so what's
different in 3.0 and then timing right i mean because the big news is it's async but as we've
as we've discussed you know a new release is coming out in in december either way and then
the question is you know how much async does it have because there'll be 3.1 and 3.2 so right so
the big thing in the python web framework world is async io and can we and can we use bring that
into jungle for us so that's on the horizon and yeah hopefully some of that will get done this
year and if we can then that will be in 3.0 but 3.0 is a time time-based release where there are
it's not feature-based so yeah the time-based release there is a release there was a release
in april there will be a release in december there will be one next september as well like 3.1
and so on you know that's the cycle of releases that we're on and what's in it is just what's
completed at that time so hopefully um for me i'd love it if there was um async functionality
at the view layer, at least, maybe at the ORM, you know, even it doesn't have to be complete.
But if there was some, then that would be great. But we'll see. The key point for me is that 3.0
isn't going to be a breaking change. It's going to be just a continuation of Django that we know
and love, 2.1, 2.2, 3.0. It could have been called 2.3. Like there's not going to be breaking
changes. We're not going to mean that you can't upgrade without serious work. It's still going
be that grab a coffee read the release notes run with the warnings so why not install the new
package so why not call it 2.3 what was i guess and this speaks to the question of so who who
decides right who if you can speak to so who says three we're going to go to 3.0 and it's going to
be in december because there is a roadmap but what how does that roadmap get developed so the the
idea was that there would be um a lts a long-term support release at the end of each major version
and then we would bump the major version for each LTS.
So 2.2 is the last 2.x release
and that's the long-term support until, I guess, 3.2.
I don't know what the roadmap looks at the end of 3.0,
but the release before...
It goes up to 3.2 as the long-term service release.
Okay, so there you are.
So the three releases and then the LTS, right?
And so 4.0 will just be the release after the next LTS.
Oh, okay.
Right, and that was the idea, was to number it that way.
But there's no...
But who's deciding this?
Can you just talk about sort of the governance of Django?
I mean, you are the Django fellow, but who do you work for?
Who do you answer to?
Well, this was...
I answer...
Well, you know, I'm contracted by the Django Software Foundation,
who are the custodians of Django, and, you know, they do all the fundraising.
So that's the nonprofit in charge.
Exactly.
But the people who govern Django are people on Django Developers.
The Django Developers mailing list is the place where Django is governed.
And there historically has been a thing called Django Core,
which was the people who contributed, they'd be invited to Django Core.
But that is in the process of being dissolved and will be dissolved this year.
And that will be replaced by governments amongst the wider community.
A lot of the Django Corps members are retired.
They're not really active in Django anymore.
And yet it makes it look as if there's 50 of them.
Well, there's not.
There's half a dozen people, really, that regularly contribute and maintain.
I know efforts to have that group reflect the community, which is pretty global at this point.
Yeah, and it's a lot of Americans, a lot of Europeans, a lot of men.
And Django is a much more diverse community than that.
And it wasn't represented in Django Core, which is populated by people who have given a lot in the past to Django, but a lot of them have moved on or aren't active now.
And so there's a feeling that Django Core is not represented.
So that will be phased out.
And then the management of Django will really occur on the mailing list amongst anybody who could...
can join that and anybody can contribute and offer
their opinion and join in
the discussion. And then ultimately, beyond
that, the Jenga Software Foundation, the board
of the Jenga Software Foundation will have a
supervisory role.
They would be the
court of last appeal, I would guess,
or however you phrase it.
Well, this is, actually, we'll link to your
talk from DjangoCon US in the fall
where, what was the title of that again?
Your Framework Needs You.
Right, where one
of the one of the points you made i think you showed the graph of the fact that it's really
half a dozen people who do the overwhelming majority of of work and then there's a very
long tail right yeah yeah and so it seems like you know millions of people use django it's it's
this amorphous thing and yet it's yourself and a small handful of other people who really make it
happen and basically largely unpaid too uh yeah so there's um i mean you're paid the fellows
contracted but other than that it's volunteer work but you know there are a few major contributors
that i you know that if you quiz them directly well it's part of their work you know right well
yeah right yeah well because that's the other thing of you know who who are these jank you know
django core people it is a mix of of individuals at larger companies and then um quite a lot of
consultants actually or individual contractors yeah because people use people using django and
they want it to work well and they want to work for them and they build their business around it
right in some ways i guess if you're that's the dichotomy is if you're on a major
you know say you're at a huge company you have you're getting paid by your employer to dive in
and solve this particular issue that will generate the community whereas if you're a consultant and
you're building half a dozen a dozen new django sites in some ways you're more apt to be able to
try out and use the new features and uh you know yeah put them put them in practice more so than
a more established site yeah i mean you know big big installations they they have trouble
keeping up with what you know i say oh it's just a day to update well kind of like if you've got
some giant thing then maybe it is right i've seen um here in boston the django boston meetup people
who are you know very experienced developers on huge projects and they they literally haven't
started a real a new django project in years yeah um you know in a production sort of setting so
there's you know no one can do everything so much to do no i mean again though i still i still think
that you're buying like the analogy i always use is you're buying a car not an ornament right and
if the the amount of when you when you use jenga when you well when you when you build any piece
of software oh right and it like a car it needs maintenance you can't just put it on the shelf
and look at it if things will break and there will be security issues and there will be operating
system updates that require you to install the latest versions of libraries to keep running
bit rot it really happens and if you don't maintain your car your car breaks down and if
you don't maintain your web application your web application will break down and it really is a
small amount of time that you have to allocate each month each nine months each major release
allocate that time upgrade your application and then not only does your car keep running does
your web application keep running but you can benefit from all the new features and it'll save
it will save you time i mean it's also it will help you hire because i mean you and i you and
i have both worked with consultants if i see a code but you know one point i just had this very
recently a 1.5 code base and you know i go i don't want to fight with that no it makes you weak
if i have a choice yeah i mean that you know i think what's more common uh is you'll have a code
base that's old but has at some point customized and gone off off of django yeah um you know again
i just had a conversation before we record this with someone he's on one five they had developers
who built something custom and now they don't know how to keep up yeah so i think that's that's
probably a little more of of why companies are resistant and get so far behind is because you
of that custom features.
And it's difficult to allocate the time.
It's like, you know,
there's always a backlog of features.
There's always a backlog of bugs.
There's always unrealistic deadlines being set
and the maintenance just doesn't get done.
It's technical debt.
It's the story of software, right?
But if you are, you know,
a somewhat technical manager
and you are trying to hire,
just for hiring alone,
update Django.
Update, update, update.
I mean, I was just at it last week.
We're going to do an interview
with a company that's big,
growing company and they are on the latest release of Django and they allocate the time
and they're trying to hire 30 engineers this year and they're gonna have a lot easier time saying
you know we are up to date yeah no and saying we're on whatever version because we don't have
the time to do it yeah and it tells you something it tells you something if you know I don't want
to upset anyone but it does tell you something about the company if they can't it's a cleanliness
the time to maintain
the product. Technical debt is real
and if it's not managed, if it comes
out of hand and you end up
in a position where your day-to-day work
is not enjoyable because you're polishing
this thing.
You're a lemon of a car instead of a brand new
maintained...
You're driving a car which is leaking oil over the road.
Right, yeah.
Okay, well I think we've covered...
Is there anything else we want to cover on the major points of
Django versions? Because this is something that
we've wanted to do for a long time.
Yeah, like, you know, the LTS is important and it plays an important role.
And there are some companies for which it's appropriate.
But in general, I would say you should default to being on the latest major version.
And you must allocate that time every nine months to update it.
Yeah. And if you run it with the warning flags and run your test suite, it should not take huge amounts of time if you have kept it up to date up to this point.
Yeah, and that's what's good about Django now in the last few years
rather than, say, Django five, six years ago
where things were much more liable to change.
Yeah. Great. Awesome.
Well, as usual, you can leave comments at our website,
djangochat.com, or on Twitter at ChatDjango,
and we'll see you all in the next episode.
All right. Bye-bye.
Bye.