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.

Welcome, Natalia.

Thank you for having me.

It's great to be back.

Thank you for coming on.

Um, and then I'm here just MCing 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?

I am very tired because it's December.

So you know, you I'm not sure if it is psychological or if it is like a real thing, like you feel the whole year being on your shoulders.

And is in the South Hemisphere, the year uh matches the school year.

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

So there is a lot going on.

So last last week at the time of this episode, we got two major, well, two big Django 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 and and in my tiredness.

But focusing on the Django releases, you asked me about the feature release for 6.0 um and what it takes.

Yes.

So Django has a release cadence of uh feature releases, what we call it, every eight months.

So we have this, we got the 5.2 uh on April this year, 2025, and eight months later we got 600, which is the release that I made um um almost a week ago.

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

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

On feature freeze, we uh 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 now, since then we got the I made an alpha release along with the feature freeze, and that went out for people to ideally start early testing for 600.

We got a month between the alpha and the beta release, beta release.

I'm not sure what's the right pronunciation.

Okay.

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 that you see in the admin, in the validators, and 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 uh for during two weeks.

And a few days before the final release, I fetch all the translations from this website and I incorporate it into what I released as the final version.

So the Angle 600 final included not only the features and hopefully most of the bug fixes, but also included the uh latest translations for uh the strings that we changed between 502 and 6.0.

I can go into into deeper details, but maybe that's not uh where we want to go to.

So you're just spending three basically three months in putting together the final release, even after all the development that's gone on.

It's not a trivial process.

And 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 uh, you know, a release date.

Because every day you start your fellow day, it's 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 um my my my my main fear is to forget a release day, basically.

Yeah, yeah, right.

Imagine you just halfway through the morning inside.

Like I've seen that some people they'll take what they call book leave when they want to, you know, write a book and they just stop everything for months at a time.

And that sounds like a nice indulgence.

You should have like feature freeze or you know, major release leave, right?

It's just like don't distract Natalia or whoever, you know, or Jacob, you know, they're busy.

I mean, but for for for what it's worth and in recognition to the other fellows, uh Sarah and Jacob, they are very mindful of this and they have been very supportive.

And I have been openly saying, my focus right now is uh the feature freeze or the beta release or or whichever.

And I have been um putting things or suggesting the things to be on others' people's plate, and I've been focusing on release.

So that's sort of already there.

And and it's also a necessity because if we want clean releases, we need to focus and and and and prioritize that.

Carlton, I recall there was a time where you were almost solo, purely solo, you know, way back.

No, no, no,

no, no, no, no.

Not really.

Um I think

Marish came

before Maresh

came on.

So it wasn't too it wasn't too long a period.

Tim Tim was Tim was still helping for quite a while.

He was always watching closely.

Uh well hang

You said something there about the t about the testing.

You said two things.

You said, first of all, ideally people would start testing it around the alpha, and then you later on in your description you said we encourage early testing.

How do we how does that go?

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

I'm I'm not blaming anyone.

Uh and actually I think that we should perhaps consider doing a different job or focusing uh some efforts into better advertising or better encouraging of early testing.

Um testing team.

the team's page.

But maybe there might be individuals who find um rewarding, you know, or exciting to find issues in in early versions.

And um I think we could benefit from those.

I mean, just today I saw uh an a new ticket uh that is about CSP and and how we might have missed an integration with something, with um the assets objects, which I'm not very familiar with, so I need to investigate a little bit before finalizing the triage.

And and I was wondering, uh, I wish we had had this feedback earlier, and even in the PR.

This PR was open for so long, and we tried to advertise it.

The Certain Council uh actively reached out asking for is there something that you want us to advertise for getting more eyes on?

And and they did, they did uh 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 um in the in the alpha release.

Um I don't know.

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

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

Do you have ideas?

Is that we if we had an example um Toxconfig, say, um, which just says, look, here's how you can test in the t in Django standard testing docs, here's how you can test your existing Django project, your existing Django version with a Toxconfig, really simple one.

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, because I think a lot of people just don't know how to do it.

It's there was a part, there was a post this week from um Seth oh Seth surname escapes me um momentarily, who's the Python security um, yes, thank you.

Seth Last.

It's like his did a post about how deprecation warnings don't work.

And we have the same problem in Django, is we will 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 two the second release later, and then there'll be the final release will come, not the pre-releases, 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.

This but people don't know how to run with warnings.

We should show them more, is all.

Is my thought.

So I agree the how, but also, I mean, Django has a marketing problem.

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 five 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.

So um

What do you think?

Yeah, no, obviously, you have to agree.

No, no, I'm not sure.

Final gentlemen have given us.

Uh uh disconnecting in a way, because the first thing that I thought where you will uh you were speaking, uh Will is that what we re 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 I I really don't know.

I've been struggling to do it.

What it absolutely is the generational.

When Sarah comes back, we can have her do it.

You're the

No, no, no, I don't know.

I don't want to put yeah, no, no, no.

I agree.

I'm actually I'm writing it down in 2026 is like video year.

So I agree, I agree.

People need a video.

Even me, I've gotten stupid.

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

I think that could be useful.

And also I think that we should ideally advertise that a little bit more uh within the D'Angle 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 D'AngleBudget.com website, uh, 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-to's more engaging and prominent.

Uh, I think that will be one step forward.

And then but but then there is this thing that I that I ponder on every day: the generational thing, the the how-to-do thing, things.

I'm not sure if the youth, maybe, maybe I I don't want to just think about age.

But um I'm I'm struggling with uh ticket reports, security reports, PR things, where I feel, and I'm I I will try not to be judgmental, but I feel like people do not read.

They do not read, they they just throw things together usually via uh an LLM or something in between.

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

Uh how people not reading maybe the progression 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 re 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, genomically not possible that you could catch 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 reissues to come in.

Whereas you know, it's almost right.

I mean, this is not a new issue, but AI slop or AI assisted slop.

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.

I mean, if there is a positive use that we can that we can uh take from the LLMs into help with the alpha testing, early testing, or encouraging people, or I don't know, can we train them on the side to recommend 6.0 in early staging?

I don't staging, sorry.

I don't know.

I'm open to ideas though.

And so maybe the new contributions uh we're struggling as you know, aren't hard o 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 well 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 anti that we're we're we're not letting the new flowers bloom.

I don't know.

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.

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?

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

Um that has been great.

I think that um having that within core and and and and having a clean way of defining the fragments of your templates that you want to reuse allows for much well finished designs and and and and a clean cleaner layout of your templates.

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

My only concern, that's how this is 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?

Uh at a different way of finding those other than using grep.

Um, but other than that, I think that's great.

What are your thoughts?

So I'm obviously enamored too.

Um look, like so it's really nice to see it go to it.

So I, you know, I started my new project and I read um Carson's essay on the HTMX website about um template fragments, and I was like, okay, I need that for Django.

And so I sat down and wrote it, and then um talked about it in um Django Europe in uh Edinburgh, and everyone was not everyone, but like it was a good it was a good take up and everyone was pleased, and there was um peep there was um 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 like tweaks found, but then after that it very quickly stabilized and you know, 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 that's you know, it's really uh rewarding and it gives me a nice little warm feeling.

And Farhan was amazing.

Um, the bottom line is I'd I've got I I was looking through my uh 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 didn't get it done, so I rebased it against 5.1, I didn't get it done.

It was never gonna 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.

He 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.

Um, and he's got a Jan um a nice API example called Django Rapid, which is um just Python, um, but it's using message spec to do the 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 the serialization there rather than the request-response cycle, which is kind of cute.

And then he's built also a um uh kind of uh in-browser Django REPLink.

And the sort of thing that, you know, only a youngster, infinite free time and energy could possibly produce.

I'm getting flashbacks to Sage when he, I believe, did a Google Summer of 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 take your project to the next level.

And and I actually uh think that it matches the other contributors that we have had that have also um helped uh and and drove major features to 600.

We also have uh CSP, Content Security Policy Integration, uh landed in 600.

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 and and made it Django quality, like you just said, Carlon.

And that's currently uh for everyone to try out.

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

Um I think it's a great thing.

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

It's it's sort of difficult, it's complex.

Um, I think there was a period where the third party, the third party package has been maintained for a long time.

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

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 bolt-in that only a few people need.

This is something that should be available and it needs that those kind of um, I don't know, that just that extra guarantee that being in Django itself provides.

Um, and I think to have it merged is like, yeah, 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 court is is exciting and good and worthwhile.

And you know, if people want to get started, 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.

And I think that's very enlightening and can help tighten the security of any site.

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

Um but it's a really nice defense in depth mess measure.

You know, if you've got uh template um escaping on and you filter all user import and thing, it's 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 uh 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 I yeah, I'm really excited by.

I just agree agree agree.

And I'm as as you're talking, I'm I'm currently actually for real on the work 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 pair the.

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, opinionated 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 d discernment.

Carlton, did you have a thought there?

I meant you don't want to put it in the beginner side.

The third major feature is background tasks that Jake Howard led the development of.

Do you want to, or can you speak to that, Natalia?

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 we wouldn't iterate that quickly.

We we did iterate it quickly uh when we approached the 620 feature phase.

And he's just uh great to work with.

Um I'm I'm very thankful for having met him and having uh gone through that process with him.

And the quality of the work that he has uh shared, done, and landed now in Django Core is great.

Um so I think that one note that is important to share with the audience is that uh there has been some recent confusion about what is the background task that we have shipped with shipped with the Angle.

And I wanted to share that that.

That's the definition of an API, sort of like in a generic way of a background task uh worker engine to plug into Django 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 Angle background tasks will define how they should speak with the framework.

There is a way to defining the tasks, to defining how a task is in queued, uh, how a task result is inspected, and well, a few of the bits.

There are, of course, settings for your project to define which background to use, with which different options, and a few of the bits.

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.

Django Toss TB.

Yeah, yeah, what's it called?

Django Toss TB 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.

It's like, no, that we 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 this the the API contract here, and it's the API contract bit that's in Django is entirely the same.

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 that's out now.

I think I think when I read a couple of the blog posts, I was like, hang on, we've we've got the messaging slightly wrong here.

It's not that it's not production ready, it really is.

Just use, you know, dbtasks as the as the background worker and you're there.

Because I mean that that's yeah, but

We should be like, look.

Because that's that's a question for me.

Like, because I I haven't technically and sorry to make this, you know, I I'm sort of partial to Django Q2, but I don't do a ton with tasks.

This is an open question for me, is right.

I'm gonna introduce, here's the thing, you can use it locally, but for production, should I make a recommendation or

Sorry to let me just answer Will's question directly, and then you jump in and tell us what you think.

But the the um the way I would 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 Q 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 but the back, the but database backends are.

But the messaging seems to be, oh, there's no backend.

It's like, no, there is a backend.

Jake spent, you know, an absolute age developing it.

Go on, Natalia.

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 uh I do know that I believe RQ2 is already uh listed in Django Task, and there is at least a shim that allows you to work uh with it using the new API.

And I also know that there is an in-progress PR for the Angotask 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.

Well, I think that different projects might need different cues because the different queues might have slightly different either focus or performance, whether you have you may have a gazillion messages and not that many queues, so you will have a gazillion cues and not that many messages for whatever reasons.

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

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

Um I there might have been a um a misunderstanding.

I when when you were saying that, Carlton, I was thinking over and over people do not read because if you read documentation, yeah, they don't read the it will say, I mean, I've established this.

I 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 uh in this release we were providing the immediate and the dummy backend that were only for development and testing purposes.

And um 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 docs, like we reiterated this concept and we linked to the ecosystem uh page, the new one that the Sterling Council 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 backend into Django Core.

I think that would be a good addition.

But I'm excited about the task thing.

Like Jake, Jake um presented it, I don't know, back in the day.

We were in

Was that in Galicia?

Or Vigo.

We're in Vigo.

Yes, I missed it.

You'd get a different answer from every um 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 um 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 backend you use.

I don't have to cover salary to cover cues and tasks for someone, right?

To make an exaggerated point.

They might they might just use the immediate or dummy backend for development, and and you might just focus on your specific background uh worker runner at some later point or with a specialized person.

You can have cues, you can do CSP policy, you can 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 what 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 celery 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.

Well, what to say what to say?

Nothing to say, I've left everyone speechless with that.

Uh there is one more um set of features that I want to highlight for Cero because the work made by Mike Edmonds was amazing and it's really worth calling out.

Uh, he has done a set of improvements when in everything that is uh email related.

There was a big branch modernizing all the uh email API using 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 a 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 incompatible 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 name arguments to be only allowed to be passed as a name 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 focused and well spent.

And I'm very thankful for how he approached that because he was really thinking about maintainers, the maintainer work on what we go through when we need to handle those cases.

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

And um that work is sort of unglamorous in a way, but it you know, necessary to excavate, okay, how do we make this change?

And so, you know, absolutely what you just said.

And from the point of view of the release manager, which happens to be me, um I felt so uh contained and and and and and so supported by his work.

And I really think it's worth calling that out because while the fellows are have this title and and and we might be in this pedestal from from from the point of view of other people, sometimes we don't know what what we're doing, or we don't know for some areas of the angle.

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 and with the patience and the care to explain a concept, to provide rationale, to provide side information, uh thorough analysis of how they are reaching the conclusion they're reaching, and uh how they are uh um going into or advising in one direction and another one, uh, give us the maintainers and the people that is making decisions, uh, it it removes stress from us, or at least

it did for me.

There's 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.

Yeah.

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

Uh the insides of the template rendering engine, I never looked into it until template buyers.

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 and what it needs to run.

Is there anything you wanted to slip in on 6.0?

Um it's just another solid um, you know, in incremental change.

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, uh 6-0, amazing.

It's just like it does keep coming.

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

Like, well, if 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.

Um, 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 is Jake the release manager for that?

I don't know actually.

Uh yes.

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

And um, 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 obliged Jacob to be release manager for 6.1.

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

And yeah, I'm looking forward to that as well.

You can see the 6.1 release notes under development.

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

Yeah, yeah.

So I personally I wasn't able to pay attention to 6.1 uh development.

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

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

But it's yeah, it never stops.

And and um maybe a talk for another time.

But I'm very curious on the Calvert 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.

And the main motivation motivation is to tie in better with um 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 uh live versions of um Python now.

So I think Python 3.10 is the lowest, and Python 3.14 is the is the highest.

So there's five whole versions there.

And um Django's release cycle was created before they s Python switched to that cycle.

And so we the 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 it's it it would be nice to A cut the number of birth 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, 5.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 a 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 a semantic version, it's like a new major version, but it's not.

Um, it's just a a continuation of Django's rolling releases.

So um I put a um I put uh 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.

And there's a Django forum post that we'll link to from you, for you, Carlton, with a lot of discussion as well.

48 messages.

And so if it's tw Python, if it's Django 26, well, you know it's supported till 29.

And if it's Django 27, it's supported till 30.

If it's 28, it's supported till 31, etc.

Um, I think that would give people a bit more clarity as to um what version they're on and when they need to act.

There's three releases a year.

We just had our third one, so it's 2025.3.

Next year will be 2026.1.

Um I think it's helpful.

Yeah.

It's it's yeah.

You I know you've said a lot already.

Or anything.

Anything.

It's boring.

I mean, I I keep I'm constantly struck by the fact that fellows, you know, people use Django and assume it comes from no 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 I wanted to say something along those lines in that the the DSF, the Dyango Software Foundation, pay one and a half person right now in order to ensure that the Angle is maintained.

But we can't possibly do everything.

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

So Diango 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, to 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.

Um I but I think the involvement of contributors and volunteers is key.

And I think that the angle is what it is because of that, but needs uh a lot more of that to continue being an excellent web framework.

Um we're struggling a lot, as I mentioned already, with LLM uh results, which are low quality, unreviewed, and and 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, is to please people to review what you're sending to open source in general because it's it's consuming a lot of time for maintainers.

Yeah, I think that's the core.

The bottom line is there's one and a half full-time people pay like pay 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 an ops meeting and just all the things you and um 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 show when it may be.

Yeah.

Yeah.

Everyone, check out 6.0, give feedback, and um thank you again, Natalia, for taking the time.

I really enjoy.

Bye bye.

Bye bye.

Learn more about their services in the link in the description.