Transcript: Django 6.0 - Natalia Bidart

More on their services later in the show.

Hi, welcome to another episode of Django Chat. I'm Will Vincent, joined by Carlton Gibson.

Hey, Carlton.

Hello, Will.

And we're very pleased to welcome back Natalia Bidart,

Django Fellow and Release Manager for Django 6.0. Welcome, Natalia.

Well, I feel honored that I'm on with the release manager and then also the author, co-author of one of the major features, which is template partials, which we'll talk about. And then I'm here just emceeing it all. So we'll start with, how are you doing, Natalia? Because maybe people don't know, but as a Django fellow, it's a lot of work to do a release. Could you speak a bit about what that process is like? Is there follow-up work you have to do after a major release comes out?

So, we have a full school year in our shoulders as well, and holidays are starting this Friday, actually.

So, there is a lot going on.

So, last week, at the time of this episode, we got two major, well, two big younger releases, not major.

And this Friday, we're having like a release of first grade from my daughter.

So, that's also like a big event.

And then everything is entangled right now in my head.

and in my tiredness.

But focusing on the Django releases,

you asked me about the feature release for 6.0

and what it takes.

So Django has a release cadence of feature releases,

what we call it, every eight months.

So we have this, we got the 5.2 on April this year, 2025,

And eight months later, we got 6.0, which is the release that I made almost a week ago.

During those eight months, the things that happens are feature development, which takes approximately six months and then a little bit less, five months maybe.

And then we have a feature freeze that happened on September this year.

On feature freeze, we no longer add features to what is going to be the 6.0 release.

To do that, we do what we call, we cut the stable branch.

So all the feature development between April and September happened in the main branch, in the Django main branch.

We landed all the things, documentation, features,

backward and compatible changes if we have to

with the deprecation path and those things.

On September, I branched from main and stable branch

and that was the freeze of the features.

And since then, I made an alpha release

along with the feature freeze and that went out

for people to ideally start early testing for 6.0.

we got a month between the alpha and the beta release i'm not sure what's the right

track all the main bugs with the features the new features that we have released

um i did the beta release uh mid-october and then we got another month until the release candidate

which was around mid-november at that time we also do what we call a string freeze all the strings

that are shipped with django inside django so you know all the messages that you see in the admin

in the validators and in in different parts of the django framework nor the docs the framework

itself, we do a freeze and we no longer allow for changes to be made to those strings because

in mid-November, we call for translations, for translators to go to the site where we

have the available strings to translate and we encourage them to do translations.

So that was for during two weeks and a few days before the final release, I fetch all

the translations from this website and I incorporated into what I released as the

final version. So the Angus 6.0 final included not only the features and hopefully most of the

bug fixes, but also included the latest translations for the strings that we changed

between 5.2 and 6.0. I can go into deeper details, but maybe that's not where we want to go to.

So you're just spending basically three months in putting together the final release,

even after all the development that's gone on.

It's not a trivial process.

I mean, for me, one non-trivial burden is to remember at which stage we are in,

when the next release is happening.

I have tons of reminders in my calendar not to miss a release date.

Because every day you start your fellow day is like you have security reports, you have bugs to try it, you have PRs to review, you have messages, you have meetings, and you may also have releases.

So my main fear is to forget a release day, basically.

so that's sort of already there and it's also necessity because if we want clean releases

we need to focus and and and prioritize that well and this is also why we have multiple fellows

no no no no no not really um i think i thought there was a handoff period which uh i'll maybe

wasn't too there wasn't too long a period it was that's true tim tim was tim was still helping for

quite a while yeah i mean and tim would pop his head up a year and a half later be like oh you

forgot to do x particular thing which was always okay he was always watching closely well let's um

let's dive right in well hang on hang on hang on hang on hang on hang on you said something there

about the testing, you said two things.

You said, first of all, ideally,

people would start testing around the Alpha.

And then later on in your description,

you said, we encourage early testing.

How does that go?

Do we get enough people to pick it up

and give it a run?

I feel that we don't have enough people testing.

I'm not blaming anyone.

And actually, I think that we should perhaps

consider doing a different job

or focusing some efforts into better advertising

or better encouraging of early testing.

Let's go, we need another team on the Teams page.

because I think that's too much.

But maybe there might be individuals

who find rewarding, you know,

or exciting to find issues in early versions.

And I think we could benefit from those.

I mean, just today I saw a new ticket that is about CSP and how we might have missed an integration with something, with the assets objects, which I'm not very familiar with.

So I need to investigate a little bit before finalizing the triage.

And I was wondering, I wish we have had this feedback earlier.

And even in the PR, this PR was open for so long and we tried to advertise it.

The steering council actively reached out asking for, is there something that you want us to advertise for getting more eyes on?

And they did publish a post regarding CSP and encouraging people with some domain knowledge to go to the PR or to test it when it was already in the alpha release.

I don't know.

I wish we had more people doing that testing, that exercising.

I'm not sure what we can do about it.

Do you have ideas?

If we had an example, ToxConfig, say, which just says,

look, here's how you can test in Django standard testing docs.

Here's how you can test your existing Django project,

your existing Django version with the ToxConfig.

Really simple.

It doesn't have to be like, you know, eight versions of Python and all the rest.

It can just be like your current version of Python, maybe the next version of Python,

plus your current version of Django.

And then if you want to just an example of how you do the pre-testing, you add this line

to your toxconfig and you can run your test suite against the upcoming Django.

And I think if we could just smooth the part, I think a lot of people just don't know how

to do it.

There was a post this week from Seth, oh, Seth's surname escapes me momentarily,

who's the Python security developer in residence.

Seth Larson, yeah, he's great.

Yes, thank you, Seth Larson.

He also maintains URL lib3, and they've had a deprecation warning in there

for about three years or four years or five years,

and they finally took it out, and they broke everything,

and they had to put it back in again.

It's like he did a post about how deprecation warnings don't work,

And we have the same problem in Django is we've got a really good deprecation process and we've got this pending deprecation warnings and we've got these deprecation warnings and then we'll remove it the second release later and then the final release will come.

Not the pre-release, the final release will come and someone pops up on the forum with, oh, you've broken my workflow with this breaking change.

It's like we've been warning you about this breaking change for the entire last cycle, but people don't know how to run with warnings.

We should show them more is my thought.

so does python like we don't we don't have a newsletter you know we don't have email capture

i can say this because there's this django news newsletter that reaches you know almost 5 000

people but there's 5 million people or something that use django so i think we need both nice steps

But also, I think we're kidding ourselves if we think that people that listen to this podcast, read the newsletter, are on LinkedIn or on X, represent anything more than 0.1% of our users.

What do you think?

No, obviously, you have to agree.

It would be interesting if you disagreed, actually.

Disconnecting in a way, because the first thing that I thought when you were speaking, Will, is that what we really need is a video from Will showing how to test early.

Because, I mean, Carlton was saying people don't know how to do it.

And I've heard requests from people saying we want videos explaining things and we don't want to read.

That might be a generational thing, which I really don't know.

I've been struggling personally with-

No, no, I agree. I'm actually, I'm writing it down, and 2026 is like video year.

So I agree, I agree. People need a video.

Even me, I've gotten stupider.

And this is how I do to try other versions of Diango with my project.

Not even, I mean, alpha releases, but maybe other versions or other Pythons or things.

I think that could be useful.

And also, I think that we should ideally advertise that a little bit more within the Diango website.

I'm not sure the reach that we have in the website.

I honestly don't know.

If we think that we have enough reach via the danglebudget.com website,

I think that we could evaluate doing more of what the current steering council is doing

into putting some pages acting as a hub to summarize good content and packages.

And maybe we can also start summarizing resources and making some how-tos more engaging and prominent.

I think that would be one step forward.

But then there is this thing that I ponder on every day,

the generational thing, the how to do things.

I'm not sure if the youth, maybe, maybe.

I don't want to just think about age.

But I'm struggling with ticket reports, security reports, PR things,

where I feel, and I will try not to be judgmental,

but I feel like people does not read.

They do not read.

They just throw things together,

usually via an LLM or something in between.

But even if it, I mean, I'm not sure how to address that,

how people not reading maybe the application warning

or docs or how to, I don't know.

It's like you can write a blog post and you can read it a hundred times and you'll think,

yeah, I've got all the typos and then you can hit publish and you can load it up in

your browser and then you will spot the typo that you've missed and then you'll fix that

and then you'll reload it and then you'll spot another typo that you've missed.

And there's no way that you can spot, it's physically, gnomically not possible that you

could capture those typos until you've hit publish.

So maybe it's the same with software releases.

You just have to let it out and then wait for the issues to come in.

So, I mean, until you've had to be on the receiving end of this, I think it's hard to appreciate what it's like, right, to get requests from people who haven't fully read this or that.

never there before because without these tools people couldn't contribute in any way and so

maybe the new contributions that we're struggling as you know i've overworked maintainers we're

struggling to to deal with them but i don't want to be i don't want to say oh no you mustn't use

such tools because that's just a kind of oh you know only only the existing contributors please

type gatekeeping there's a word for that gatekeeping i worry that if we if we we're too

i will work on a video for that for next year videos is my focus as much as i can for next year

thank you could we talk about the features in 6.0 yeah is there anything else we okay so well

natalia you speak in paragraphs what would you we will link to the release notes what would you say

are the major features people should be aware of um okay so i highlighted those in the release

So, the feature that, I mean, one feature that is very famous and people have been mentioning in keynotes and in conferences is, of course, Temple Passions, which was originally created by Carlton and brought to the Ango Corps in the context of Google's Summer of Code with Farhan as an executor and Carlton as a mentor.

That has been great.

I think that having that within core and having a clean way of defining the fragments of your templates that you want to reuse

allows for much well-finished designs and a cleaner layout of your templates.

I have been using it in another project and I'm very, very in love, I will say, with how you can define the pieces in your templates.

My only concern, that's a personal concern, is discoverability, how you can, in a way, have an index of what partials do you have and where are those when you need to reuse it.

a different way of finding those

other than using grep.

But other than that, I think that's great.

What are your thoughts?

So I'm obviously enamored too.

Like, so it's really nice to see it go.

So, you know, I started my new project

and I read Carson's essay on the HTMX website

about template fragments.

And I was like, okay, I need that for Django.

And so I sat down and wrote it.

and then talked about it in Gen Con Europe in Edinburgh,

and everyone was, not everyone, but it was a good take-up,

and everyone was pleased, and there was the inline argument

where you can define the partial and output it at the same time.

That was added very early, and there was a few tweaks found,

but then after that, it very quickly stabilised,

and it wasn't like there was a continual drip of new features,

and so that was lovely.

And then to have it merged into Core is just like,

oh, well, that's lovely.

That's, you know, it's really rewarding

and it gives me a nice little warm feeling.

And Farhan was amazing.

The bottom line is I've got,

I was looking through my Django checkout the other day

and I've got a branch from Template Partials

that I started against, I don't know, 5.0

and I didn't get it done.

So I rebased it against 5.1.

I didn't get it done.

It was never going to happen

because it just took too much time

and too much effort to bring it up from,

yeah, this is a fine third-party package

to this is Django quality.

For me to commit the time.

So the Google Summer of Code project was exactly what was needed to add, to give it the momentum

to get it actually into core.

I'll just shout out to his Django Bolt project, which is Rust-powered API framework, but he's

doing lots of interesting stuff.

And this is like, you know, you suck people in, you're like, Google Summer of Code, get

a feature in, and then hopefully, hopefully they stay.

interesting rust based thing um and he's got a nice api example called janga rapid which is

just python um but it's using message spec to do serialization and comparing that to say drf type

approaches it's you know nice and quick and just using that you get kind of fast api type performance

um showing that the you know the issue is the serialization there rather than the request

response cycle which is kind of cute and then he's built also a um kind of uh in browser

django repel oh django repel yep you can define you you yeah you can define your project you can

create a um so he's got a wasm based uh sequel light there you can define your models define

your migrations run your migrations and run the whole project all in your browser and it's

it's just kind of really cool and the sort of thing that you know only a young yeah it's new

infinite free time and energy could possibly well and i'm getting i mean carlton we can

code and then you know now he's wagtail core team and doing lots of stuff and so um there's a feeling

of i had nothing to do with either of them you did with both um you know this is how it should

be right like you bring people in who are smart and eager and have new perspectives and they you

know enrich the ecosystem i would say hacksoft is your development partner beyond code from custom

software development to consulting team augmentation or opening an office in bulgaria they're ready to

that it matches the other contributors that we have had that have also um helped uh and and drove

major features to 6.0.

We also have CSP, content security policy integration,

landed in 6.0.

That work was led by Rob Hudson.

He is the maintainer of the third-party package,

Django CSP.

And we took like the core of that

and made it Django quality, like you just said, Carlon.

And that's currently for everyone to try out.

And I'm not sure if you use it in your projects.

I think it's a great thing.

It's one of those things that I think really belongs in Django itself.

It's sort of difficult.

It's complex.

I think there was a period where the third-party package

had been maintained for a long time.

I think there was a brief period where it was kind of in this

un-maintained limbo.

I'm not 100% sure on that, but I'm pretty sure that happened.

And it's like, hang on, this is an important security feature.

it's you know it's not some i don't know custom field bolting that only a few people need this

is something that should be available and it needs those kind of um i don't know they're just

that extra guarantee that being in django itself provides um and i think to have it merged is like

yeah now that's good for the long-term stability the long-term um assurance it plays into our

security record it plays into you know django's story about being a strong solid foundation you

can rely on i think for all of those reasons to have it merged into core is is exciting and good

and worthwhile and you know if people want to get started that you can just set it up to do the

reporting bit to begin with and that's a lovely way to just begin and you get the errors in your

browser and it's okay yeah now i can fix them and then you can turn it on for real just a little

csp policy for your website with some basic configuration which is socially safe and not

too restrictive and you will get reporting of the potential violations that your website might have

when it comes to different assets uh usage and i think that's very enlightening and can help

If your CSP policy is too tight, resources you need just won't load

and then your website will break.

So it's worth being sure you've got it right and then turning it on for real.

But it's a really nice defense in depth measure.

You know, if you've got a template escaping on and you filter all user import,

you shouldn't have cross-site scripting things.

But to be able to say, do you know what, I'm only loading resources from my own site

or from this particular one other site or whatever your CSP policy is.

It just tightens, you know, tightens all the screws, makes you just that little bit harder to have an exploit.

So, yeah, I'm really excited by it.

Yeah, nothing for me to add.

And as you're talking, I'm currently actually for real on working on the Django for professionals.

book 6.0 update okay for real and i was just making notes on like yep need to make sure i

yeah oh for sure but yeah it's always just figuring out the level at which i want to

introduce things right because people read the books hopefully to get a curated opinion take

and so i want to figure out what do i think is bare minimum you should do and then what is what

is extra and so that's always what takes some discernment carlton did you have a thought there

yeah i just gonna say csp is definitely a professional level oh yeah you should have

it but like you don't need it as a beginner site i'm gonna include it for sure but then

you know probably i'll do something like that's not what i meant i mean you don't want to put it

in the no no yeah yeah it's too like it's something that a beginner just doesn't need to know for

sure the third major feature is background tasks that jake howard led the development of do you

said but also it was a very rewarding rewarding interaction with jake he's very easy to work with

he's very attentive to details he's very thorough and he has been uh iterating over the pr for a

long time i mean he started work before 5.2 uh 5.2 yes and he has been just pushing and updating

things and reacting to

review comments when they come

because in the first stages

we wouldn't iterate that

quickly. We did iterate it quickly

when we approached

the 6.0 feature phase

and he's just

great to work with. I'm

very thankful for having met

him and having gone through

that process with him and the

quality of the work that he has

shared, done

and landed now in Django Core is great.

So I think that one note that is important to share with the audience

is that there has been some recent confusion

about what is the background task that we have shipped with Django.

And I wanted to share that that's the definition of an API,

sort of like in a generic way of a background task worker engine

to plug into the ANGO in a way that you could,

if you need to, either replace that engine

or even have different engines in different setups of your project.

And the ANGO background tasks will define

how they should speak with the framework.

There is a way to define in the tasks,

to defining how a task is enqueued, how a task result is inspected, and, well, a few other bits.

There are, of course, settings for your project to define which background to use with which

thing in and of itself. You still need to use third-party tools, but it's a new way that the

third-party tools can probably link in going forward yes carlton well but and this ties into

what's it called jango toss tv is there you just pip install that alongside and you're ready to go

and i think um i've seen it read a few blog posts and they've got this like paragraph about how how

it's not really got a back time task so no i think we just phrased this wrong somehow is that

yeah, look, to get going, just use Jake's backend that he's been working on, that he's developed

with the API contract here. And it's the API contract bit that's in Django, as Natalia's

saying. And yes, you need to install the extra package to go with it. But the point is that the

API allows you to use Celery or, you know, if somebody wrote an adapter, you could use Celery

or Django Q2 or Jake's one or, you know, whatever package is out there. I think when I read a couple

of the blog post i was like hang on we've we've got the messaging slightly wrong here it's not

that it's not production it really is just use you know db tasks as the as the background worker

and you're there well but that's an opinionated take right i mean that yeah but we should give

to do it alongside the new api because that's that's a question for me like because i i haven't

sorry to make this you know i'm sort of partial to django q2 but i don't do a ton with tasks this

is an open question for me it's right i'm going to introduce here's the thing you can use it locally

but for production should i make a recommendation or the way i would phrase it sorry let me just

phrase would have the way i i would explain it to anybody is look that there's this new task

framework there's an api and there's a back there's a there's a worker in um implementation for it

that's the default recommended worker implementation and then the great thing is that any other queue

system can adopt the api interface and then that will be pluggable into any third-party app that

wants to use tasks or any project that wants to use tasks in a generic way the same as the back

the database backends are but the messaging seems to be oh there's no back end it's like no there

is a backend jake spent you know an absolute age developing it go on natalia yeah so i wanted to

tasks in the database i don't have clarity whether that's production ready when it comes to

retries and robustness and atomicity and a few of the bits it might be uh since the last time that

I check. But I do know that I believe RQ2 is already listed in Django Tasks, and there is

at least a shim that allows you to work with it using the new API. And I also know that there is

an in-progress PR for Django Tasks to have a shim to use Celery as well. That might need some

updates but i know it's there so and also about recommendation will i think that different

projects might need different cues because the different cues might have slightly different

either focus or performance whether you have you may have a gazillion messages and not that many

cues so you will have a gazillion cues and not that many messages for whatever reasons

It also depends on your infrastructure, whether you want to prioritize resource consumption or velocity, or you may need an absolutely bulletproof retry mechanism, or you can miss some of the packages, let's say.

So I guess it's only fair to us for projects to evaluate which actual backend they need for their domain of the project.

There might have been a misunderstanding when you were saying that, Carlton.

I was thinking over and over, people do not read because if you read the documentation that we wrote, it will say, I mean, it said all over the place.

we have ref docs for tasks we have a topics page for tasks we have the settings and the release

note in every one of those we said that in this release we were providing the immediate

and the dummy backend that were only for development and testing purposes and it is true

that we didn't say if you want a production ready backend you should go to this place we didn't say

that we made some um improvement to the dogs like we reiterated this concept and we linked to the

ecosystem uh page the new one that the steering console created so people will have perhaps more

clarity on the current status but yeah i mean definitely we're open to improvements and we

are also open to eventually merging the or seriously evaluating merging the database

back end into Django core.

I think that would be

a good addition.

we could just have

a pip extra

where it's like

an official sort of,

you know,

pip install Django

with tasks back end

or something.

But I'm excited

about the task thing.

Like Jake,

Jake presented it,

I don't know,

back in the day.

We were in...

Yeah, where was that?

Was that in...

Galicia.

It was in Dublin,

wasn't it?

Or Vigo.

Vigo, yes.

We were in Vigo.

Yes.

I missed it.

You know,

he gave this great talk

about how

particularly if you're developing a third-party package,

without tying yourself to one particular queue backend,

and there are like 50.

If you were to go on to Macedonia and say,

oh, what Django queuing backend tasks do you use?

You'd get a different answer from every person who replied.

And that's fine, and that's great, and that's the Django way,

and that's wonderful.

But if you're developing a third-party backend or third-party app

and you want to use background tasks,

You didn't have a common API you could lean into, and now you do.

And that's a major step forward.

I think it's going to be brilliant as that matures, regardless of which particular back

end you use.

And I think it, for me as an author, it makes it easier to introduce tasks because I can

go to the built-in option.

You can try it locally.

I don't have to cover Celery to cover queues and tasks for someone, right?

To make an exaggerated point.

have a Celery expert, for example, but you might have a team of five engineers that are

very skilled in Django and Python.

They might just use the immediate or dummy backend for development, and you might just

focus on your specific background worker runner at some later point or with a specialized

person.

And this is something I think that Django and I can't say it's unique among web frameworks, but it feels like so much is optimized around one developer can do so much with Django.

You can have queues, you can do CSP policy, you can do a lot of things that sometimes a team would be required.

You know, HTMX template partials, you can get an interactive website solo so much more easily than you could in the past.

And it feels anecdotally to me that some other web frameworks are more focused on, I don't know, maybe like a big client or a big website needs as opposed to Django really is focused on like you solo can have production ready internet scale site, more or less.

And there's still these areas like if you need crazy salary or what have you, but just the built in power of Django is a lot.

I don't know.

Does that make sense?

I just feel like I don't always see other web frameworks as focused on what a solo developer can do as opposed to what the broader community of teams that have front-end and back-end need.

What to say? I left everyone speechless with that.

He has done a set of improvements in everything that is email-related.

There was a big branch modernizing all the email API used in Django.

He changed all the underlying in the fundamental layer below the API that Django provides

and changed everything to use more modern APIs from Python itself.

But in order to complete that branch, Mike made a series of other improvements when it comes to how we handle Unicode for domains when it comes to URLs or email domains.

He also made an amazing work in order to be able to generalize a decorator so we can deprecate more easily signatures of public methods or public functions.

So we have this strict policy in how we handle backward and comparable changes, and it's

often the case where we want to change a given signature, and more often is the case where

we want to make some not-named arguments to be only allowed to be passed as a named argument.

He provided a decorator to make that transition and that deprecation more robust and reusable,

And I think that was an effort that was...

So, focus and well spent, and I'm very thankful for how he approached that, because he was

really thinking about maintainers, the maintainer work, and what we go through when we need

to handle those cases.

He was very easy to work with, and I appreciate a lot his contribution.

obscure and like the you know the different unico versions and whatnot and um that work

is sort of unglamorous in a way but you know necessary to excavate okay how do we make this

change and so you know absolutely what you just said yeah from exactly that and from the point

so supported by his work and I really think it's worth calling that out because while the fellows

are have this you know title and and we might be in this pedestal from from from point of view for

the people sometimes we don't know what we're doing we don't know for for some areas of the

we don't have the expertise to go deep or to make decisions about yes let's go this way or let's

Remove this or add this.

Having people with the domain knowledge and with the patient and the care to explain a concept, to provide rationale, to provide side information,

through analysis of how they are reaching the conclusion they are reaching and how they are going into or advising in one direction and another one.

Give us the maintainers and the people that is making decision.

It removes stress from us, or at least it did for me.

So I think that's very, very needed and valuable.

If people go in and look at the discussions, there's a lot of discussion, as you said, education and everything else that goes into it.

So you can't just drop perfect code and be done with it.

It's a small percentage of what's required.

because I learned a lot from all of them.

Like CSP, I don't even know it existed.

The insides of the template rendering engine,

I never looked into it until Template By Sharks.

And background task, I also learned a lot because I've been using Celery,

but I never really dig deep into what it really means to have task

and what it means to run.

Is there anything you wanted to slip in on 6.0?

No, not really.

Like, you know, every single release, I always say this, every single release, like 5.0, amazing.

5.1, amazing.

5.2, amazing.

6.2, 6.0, amazing.

It's just like it does keep coming.

And, you know, people are like, well, why still Django?

Like, well, have you looked at the release notes recently?

I mean, yeah, no news is good news.

I mean, at PyCharm, we just released a version.

And every time we release something for a variety of reasons, there's, you know, there's stuff that emerges.

The amount of things that need to be fixed is so small for something as important as Django.

I mean, it's pretty phenomenal.

But my question was, Natalia, even though 6.0 came out, 6.1 continues apace.

Is there anything you want to say on that?

Is Jake the release manager for that?

I don't know, actually.

So 6.1 started official development when we did the cut of the 6.0 stable branch.

So 6.1 has been in the kitchen since September this year.

And the fellows tried to take turns for being release manager of the different feature versions.

So, Sarah did 5.2, I did 6.0, and we have kindly invited slash oblite Jacob to be release manager for 6.1.

So, yeah, he will be in charge of the feature freeze, the alpha release, and the subsequent releases.

Yeah, I'm looking forward to that as well.

You can see the 6.1 release notes under development.

So August 2026, and there's some features that may make it around model field fetch modes, database level delete options and other things.

But yeah, it's relentless, right?

The train just keeps on chugging, even though you want to take a pause and celebrate and deal with 6.0 issues.

It's like, nope, here comes 6.1.

So I personally, I wasn't able to pay attention to 6.01 development.

Jacob has, has done that, very focused, which is great.

And it's also another thing that provides me peace of mind.

But yeah, it never stops.

And maybe I talk for another time, but I'm very curious on the Calder proposal that you

have, Carlton, because I think that will help with this feeling of overwhelming, at least

that I have.

But yeah, maybe we can discuss it.

python's annual release cycle which since 3.9 is every every year and um the issue is that there

are any given time there are five um live versions of python now so i think python 3.10 is the lowest

and python 3.14 is the is the highest there's five whole versions there and um django's release

cycle was created before they python switched that cycle and so we the the versions that so 5.2

is still supporting python 3.8 which is um been end of life for a year and a half by the time we

um by the time 5.2 goes end of life and it's it would be nice to a cut the number of births and

versions we're supporting and b get on track with the kind of forward-looking python support policy

that i think we're being recommended to to follow so that's the main reason um and then um the sort

of second one is we have this kind of gap um between uh lts versions where people kind of get

stuck on an lts and they can't easily upgrade from 5.2 to 6.0 because 6.0 isn't an lts so they wait

all the way till 6.2 which means that there's this kind of we have this drop off when the old

lts goes end of life we have people that are so the people are currently on 4.2 when 6.0 is

released so now for or in april sorry 4.2 will go end of life and people will be like oh oh i'm

still on the old lts i mounted start updating and that takes almost the entire lts cycle to get

people on to say 5.2 just as 5.2 goes end of life and it's it would be nice if every version was a

um an lts version so there's um i've got a proposal for that and then the third bit was

the calver bit is to just make it make it clearer what the version numbers um come to so we've

talked on this podcast a million times about how you know when 6.0 comes out people are like well

it's not really a breaking change it's not because it sounds as if it's semantic version it's like a

new major version but it's not um it's just a continuation of django's rolling releases so um

I put an email out about that a couple of months ago, and I will write that up over the new year period and present that and see if we can get some agreement on progressing that.

So that perhaps for the 7.0 period, that might be Django 28.

There's three releases a year.

We just had our third one.

So it's 2025.3.

Next year will be 2026.1.

I think it's helpful.

It's not, you know, it's not novel.

It's, yeah.

I know you've said a lot already.

No, no, anything. Open floor. Go on.

That's boring.

No, just about being a fellow, just personally.

I mean, I keep, I'm constantly struck by the fact that fellows, you know, people use Django and assume it comes from somewhere indeterminate.

And at the end of the day, it's fellows, it's people you called out doing the work, you know.

There's real people doing hidden work to make all this happen.

I wanted to say something along those lines in that the DSF, the Diango Software Foundation, pay one and a half person right now in order to ensure that Diango is maintained.

But we can't possibly do everything.

There is no time and we don't have nor the energy nor the time to do everything that is needed.

So the angle it is what it is today because of the effort of and contribution from a lot of volunteers.

The paid persons, the fellows, we try to, the best that we can with those efforts,

we try to provide support, try to provide reviews or advice or execute the bits that other people cannot execute.

But I'm finding myself more and more overwhelmed with the amount of things that are coming

our way.

And without the help of the volunteers, I don't think that we could keep up.

I mean, we're not even keeping up, but we're keeping up with priorities.

We're not keeping up with everything.

But I think the involvement of contributors and volunteers is key.

And I think that Diango is what it is because of that, but needs a lot more of that to continue

being an excellent web framework.

We're struggling a lot, as I mentioned already,

with LLM results, which are low quality, unreviewed,

but they're taking a lot of time.

So that's also an open thing that I don't have any answers

nor any concrete proposals yet,

but it's also that we are struggling a lot with.

So if I can ask anything,

it's to please people to review what you're sending

to open source in general

because it's consuming a lot of time

from maintainers.

Yeah, I think that's the core.

it seems that people think

either Django sort of comes out of nowhere

and they have no idea where it comes from

or they think there's some massive corporate entity

with a massive team

and like lots of resource.

The bottom line is

there's one and a half full-time people

paid to work on it.

There's very little resource

And I think it's important to keep that in mind as well.

Well, Natalia, thank you for taking the time.

I know just before this, you had an ops meeting and just all the things you and Jacob and

Sarah juggle.

It's so impressive.

And Django wouldn't be what it is without, especially the fellows.

So thank you for your work and not going insane, managing everything.

I appreciate it.

Well, publicly.

We'll see the show when it may be, yeah.

We will have notes to everything.

Everyone, check out 6.0, give feedback.

And thank you again, Natalia, for taking the time.

I really enjoy.

Bye-bye.

Bye-bye.

This episode was sponsored by Hacksoft,

your Jenga development partner beyond code.

Learn more about their services

in the link in the description.