Transcript: Django Versions

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 are you doing?

You are as much as anyone responsible for the releases of Django, right?

Yes.

So that one of the key points about the fellow program is that we handle the releases.

And so we do those monthly, normally.

And yeah, that that's a key role.

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?

He's just stepped down and now it's um myself and Marius who do the who are the current Django fellows.

So, you know, if you if you want to come and review a pull request, then please do.

Um there's a check a patch review checklist, and that would be amazing if you want to come in.

We'll talk in another episode about contributing more to Chango.

Um but then once all the commits are in, Maris and I are responsible for rolling the release and putting it up on Pype I and making it available to you.

So let's talk about so 2.2.

Um 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 and then we can talk about you know why the switch to starting with to 3.0 and 3.1 and all the

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 1.0, 2.0, and 3.0 is there'll be a long-term support for each major version, and that's so as well beyond the initial nine months where a version gets 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, uh, a whole other two years, I think, or

however long.

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 uh 2.1, 0.1, 0.2.

These are the smaller, what's the technical term?

Those are the generally security.

I mean, unless there are no changes, but there will be changes.

And in that point, it gets bug fixes.

Any bug fixes that come in within that first nine months get put get um included in the current version, whichever is the current version.

That's what mainstream support means.

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.

Probably nine months.

And that after that, there will only be a release if there's a security issue or if there's a data loss buck.

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.

In the same way that 111 was the previous long-term support release.

So 1.11 has continued to be updated for 2.0, 2.1 years.

Yeah.

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 the latest bug fixes getting put in.

But then they'll only get a backport of another fix if it's a data loss bug or a 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 the latest version, then they give you the stability and the security to know that for the whole life of that 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 LD 3.

So you you can stay on that for two years or three years.

Which which I think a lot of companies do to and yet we've 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 um and so you know, we've talked about you know what what are the highlights for the reasoning for that, right?

Because a company is sitting there saying, This takes time, I don't have time.

There were quite a lot of breaking changes and it was difficult to update.

These days we're we're much more conservative.

And this is 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.

Wow.

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 there's a deprecation policy.

And what does that mean?

It will be in the version which so say we introduce a um a deprecation now in 2.2, it will be pending deprecation in 2.2, it will be deprecated in 3.0, and it'll only be removed in

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.

Well, 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,

But let's say you're on 1.11.

Yeah, 1.11.

If you're not on a supported version, well, okay, uh there's time.

But the the general policy is the same, it's just gonna take you longer.

So from 1.11, run with the the deprecation warnings enabled.

So um appending 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 all to get all um all

the time.

Yeah, okay.

So you have to invoke python.

And so on 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.

Oh 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, let's see.

So 2.0, fine.

Run again with the warning flags enabled, fix any warnings.

2.1, same again, 2.0.

Yep.

And and you also, you know, you of course you have tests in your project, right?

So you can run your tests.

You can create a clone of your virtual environment, you can install the latest version, you can even install Django Master from PIP, 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 the.

There's no reason why not.

Run your test, let us know if something broke that wasn't meant to.

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, uh, 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.

Like it's not just Django, it's it's it's everything.

Like untested code is broken by design, is the quote, right?

Yeah, I mean But you will see it.

You will see it and you will see crazy things you in the real world.

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, of you know, be it s using a browser-driving framework, like Selenium or something like that, or just a unit test in co in pure Python code.

You've got to test it either way.

So you might as well.

I mean, you know, people talk about test-driven development.

I think you know, some test driving is great, but for me, sometimes quite often, very often, I don't know how a code is going to behave.

I I don't think it's helpful.

Well, there's a whole bunch of talks on this.

Um I mean, David Hennemier Hansen, I think, is the most public in being uh against you know extreme test-driven development.

I think the key is whatever works for you.

Sometimes I'll do uh the test first.

Probably generally speaking, I write the test after, but immediately after, but uh it does it sort of doesn't really matter.

It 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 uh having trouble doing test driven development because it's just something that it's it's more I think it's more of an expert level thing.

I when you're beginner intermediate, it's much more appropriate to write the test after you've gotten the code working.

I would say

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 you know, 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.

I think so.

Um, 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.

For yeah, I I hit the view, the URL, and it loaded.

And what that gives you then is at least a regression test.

So you can run something.

Yeah.

Do you know check the template?

Do I use am I using the correct template?

Does the 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.

Uh, you know, so you can go through, you can test the templates, test the views, the URLs, test the models.

It's yeah, it's helpful.

We'll we'll do a whole thing on it.

Well, 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.

Well, let's let 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 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, but there are it's not feature-based.

So yeah, there will be a release.

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 uh functionality at the view layer at least, maybe at the ORM level, you know, even it doesn't have to be complete, but if there was some, then that would be great.

But we'll see.

It's it could it could have been called 2.3.

Like there's not gonna be breaking changes.

We're not gonna mean that you can't upgrade without serious work.

It's still gonna be that grab a coffee, read the release nodes, run with the warnings, so why not just warnings, install the new package.

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'll go we're gonna go to 3.0 and it's gonna be in December?

Because there is a roadmap, but what what how does that roadmap get developed?

So the 2.2 is the last 2.x release, and that's the the long-term support until I guess 3.2 would you know.

I don't know what the roadmap looks at the end of 3.0, but the the release before

So the three

And so 4.0 will just be the release after the next LTS.

But there's no it

Can you just talk about like sort of the governance of Django?

Like, I mean, you are the Django fellow, but who who do you, you know, who do you work for?

Who do you answer to?

Um but this the the people who govern Django are um the people on Django developers.

The Django Developers mailing list is the place where Django is governed.

Um, and there historically has been the thing called Django Core, which was the the people who contributed, 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 community, the wider community.

Um, a lot of the Django Core members are retired, but you know, 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 maintain regularly communication.

And there's also maintain.

Um and Django is a much more diverse community than that, and it wasn't represented in Django Core, which is is populated by people who've given a lot in the past to Django, but a lot of them have moved on or aren't active now.

Uh 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 the contribute.

Anyone could can join that, and anybody can contribute and offer their opinion and you know join in the discussion, and then ultimately beyond that, the Django South Software Foundation, the board of the Django Software Foundation will have a supervisory role.

You know, that that they would be the the court of last appeal, I would guess, or however you phrase it.

We're one of the one of the points you made, and 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?

And so

the fellow is a uh contracted, but other than that, it it's volunteer work.

Well yeah, right.

Yeah.

Well, because that's the other thing of you know who who are these 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.

And in some ways, I guess if you're that's the dichotomy is if you're on a major, you know, say you're 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, uh, 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.

I I say it's just a day to update.

Well, uh kind of like if you've got some giant thing, then maybe it is right.

Um, you know, in a production sort of setting.

So there's uh yeah, you know, keep we no one can do everything, so much to do.

And if the the amount of 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, BitRot, it 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 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.

I mean, there it's also it will help you hire because I mean you know and I you and I have both worked as consultants.

If I see a code base, you know, a one point I just had this very recently, a 1.5 code base, and uh, you know, I go, I don't want to fight with that.

If I have a choice, yeah.

I mean, the you know, I think what's more common uh is is you'll have a code base that's old but has at some point customized and gone off of Django.

Yeah.

Um, you know, again, I I just had a conversation before we recorded this with someone, he's on 1.5, they had developers who built something custom and now they don't know how to keep up.

Yeah.

It's like you know, there's always a backlog of features, there's always a backlog of bugs, there's always um unrealistic deadlines being set, and the maintenance just doesn't get done.

It's technical debt, it's the story of software, right?

I mean, I was just at it last week, uh we're gonna do an interview with a company that's um 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, and it it tells you something if you you know, I don't want to upset anyone, but it does tell you something about the company if they can't.

Technical debt is real, and if it's not managed, 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 this thing.

Okay, well, I think we've covered the 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.

And you you must allocate that time every nine months to update it.

Great, awesome.

Okay, uh, as usual, you can leave comments at our website, DjangoChat.com, or on Twitter at chatjango, and we'll see you all in the next episode.

All right, bye bye.

Bye.