Should we adjust Django's versioning to use a form of CalVer?

Django Internals
41

I’m glad we’re agreed on that :sweat_smile:

Before responding to the rest, either a Green Only or Plus Last Yellow Python support policy would see us innovating faster — since being able to use new language features so much sooner — than anything else here.

Your query implies you likely don’t believe this next but, I’ve been maintaining packages in the Django ecosystem for an age and day: You can always shim. Realistic examples where that’s not the case a few on the ground, if any.

GeneratedField is purely additive. If I wanted to start using it, I could, and just say This new bit is New Version Only™.

I didn’t follow all the details of your example about 5.1 fully… — I think the LTS one is the important one. But, yes, 12 months is longer than 8, and 3 years is longer than 2 years 8 months. I’m was absolutely aware of that making the proposal. :slight_smile:

My point is that, such a slow down is negligible given our already slow release cycle. That whether I use temple-partials or the task backend from the external package for a few more months or not makes no (felt) difference at all.

So, yeah. Rhetorically, it feels like they should, but not really in practice. As a maintainer, the burden is (still) the old LTS, and that’s already a three year window (which I wouldn’t want to cut: the LTS is important to an large chunk of the user base).

And I also think, and have half-argued but will argue more, that by leaning into this we can actually free up innovation, where we’ve spent the last few years (or so it feels) struggling there. (Django has moved on — look at the releases! — but there’s this narrative…)

I sure we could perform any number of gymnastics to modify our current release cycle to try and accommodate some of the complaints. (Aside: It’s proven remarkably difficult to do, given how well it was first thought through for the 24 LTS cycle — search here and on django-developers for threads about adjusting the Python version support…)

I’m going to say, though, that the simplicity and clarity of the annual release cycle are stand out benefits on their own. When’s it released? When’s it supported to? Both utterly transparent. What Python does it support? Not on its sleeve but, again, totally clear.

It’s a conjecture but, I fully expect the rolling LTS approach to measurably increase the percentage of projects on a supported LTS version, simply by removing the gulf between LTS versions.

And now I feel like I’m just repeating arguments I made before, so I’ll stop… :police_officer: More to say, but I hope I’ve at least engaged with your points.

42

Good point @ryanhiebert. We’d just adjust it to two years. That’s plenty already :melting_face:

@thibaudcolas Thanks yes, I see that. Happy to chat about it but see my longer reply to @jacobtylerwalls — it’s the old LTS which is the determiner here. We still always have three active versions. The difference is I don’t have to add and then remove support for the two middle ones between each LTS, I just do a FIFO queue. (I’d make the case it’s less work, over beers, but I think the other benefits dominate a marginal work change.) :person_shrugging:

@CodenameTim Yeah, I hear this. As per my remarks to @jacobtylerwalls, I think the four months is neither here nor there. The missing piece is continuing to develop the modularisation and ecosystem conversations, which I’m continuing towards — that’s where the iteration/innovation comes and can be done better. (I can only ask you to wait there. :person_juggling:) Nonetheless, even if all that is nonsense (which I don’t believe it is) I still think the Annual Release Cycle stands on it’s own as a net gain, as I’ve tried to outline.

@collinanderson Thanks for that perspective! Yes, the version that ships on various linux distributions is important to consider. I know @Emma has good opinions there. (I’m not sure which policy I favour: both appeal, depending on which way the wind blows :sweat_smile: — I did wonder if the emergence of uv, with it’s magical Python installation changes the logic at all for distribution Python users? :thinking:)

1 Like
43

Thanks @carltongibson, that helps. If it’s too hard to graft on, then there it is.

Super briefly on the shims thing. I wanted to consider “packages” that are of the size of the django admin or wagtail or arches or fieldscope, i.e. full-stack apps with their own models, generic views, and search backends. The 5.x cycle had GeneratedField, which can be used to migrate away from elastic search as @pauloxnet has written about. The 6.x cycle will have FetchMode, which will enable removing brittle prefetch_related() calls. Those don’t always have third-party backports like django-tasks. django-auto-prefetch exists, but it’s a different interface. Extrapolating from that, why wouldn’t 7.x have something of this size, offering an opportunity for a major rewrite that keeps you on Django when other voices are pushing you toward some other hotness?

Monolithic “packages” (superframeworks?) may be more frightened to add shims that need a deep knowledge of Django to pass code review. It’s easier to just wait.

You’ve satisfied my concerns. I won’t offer a view on whether the annual calendar is more transparent; it’s too hard to unlearn what I’ve grown used to :smile:

44

Yep, sure. In this case, you can still branch the whole model definition (say) on Django version. If the feature is compelling it’s worth doing. (You didn’t mention DB cascades, but that might be an example :sweat_smile:) I’m happy to grant that there is work in this. I don’t think it’s any different from what we already do is all. The extra time is short.

And then the other benefits come in on the side.

(Happy to chat further, but I think we should take it away from here, so as not to totally hijack the thread on details.)

1 Like
45

As one of the developers on Arches - a Django project with its own release cadence, I find this proposal very appealing. When we decided on our 9 month release cadence, we would have liked to have aligned it with Django’s, but Django’s was just a little too short for us. If Django were to move to a 12 month interval, Arches could potentially adopt the same schedule so that each release of Arches would support the latest Django and Python versions. Syncing our cadence with Django’s would provide Arches developers and administrators with a great deal of clarity about what versions of Django and Python they can plan for when they consider upgrading Arches. Although a 12 month interval is a bit of a wait for new features, it would be manageable, and I think worth the wait.

2 Likes
46

It doesn’t change anything. DeadSnake was already providing easily obtainable python version. The crux of the matter is that distributions ship with nginx (or other webserver) that has a relevant compatibility layer to the distribution’s uwsgi that has a python plugin for the system python. The whole system is rigged to work with the system’s python (that does get security patches).

Compiling your own plugin for uwsgi and having different versions of that plugin is possible, I have done it in the past. But it’s not a matter of doing a pip install -u or apt upgrade which means that the plugin often fails to get updated with security releases of python, which in turn is a vulnerability.

On machines that host several projects, having a pip-installed uwsgi is inferior in many ways to ahving the system-wide uwsgi running from the init scripts.

TL;DR; installing a version of python and creating a a virtualenv was never the issue

1 Like
47

I just want to chime in and say that I’m very much on board with the ideas to
have a clear consistent release rhythm AND change versioning to something which
has meaning.

As a maintainer of third party packages, maintaining the “matrix” of
Python/Django to support can become quite the hassle.

The release alignment with Python, together with a semantically meaningful
(which I feel years are) numbering, will make the releases of Django much
easier to reason about and plan after.

The slower cadence we would be introducing is in my opinion a small price to
pay. One could argue that a simpler release schedule removes cognitive overhead
for third party maintainer, and thus there is a better story for shims to be
maintained.

I’m think your suggestion @nessita about moving the pre-release phase as to not
cross the new year makes a lot of sense. My only concern about overlapping an
Python release is nullified by the feature freeze for Python being in May with
the first beta. It also makes the math for support easier (in my head): The
2025 release is supported until (and including) 2025+3=2028, as opposed to a
release in January which would mean support ends at (but not including)
2026+3=2029.

1 Like
48

I’ve been pondering this… (it’s the one comment still on my TODO list) — Exact release schedule is a fine details question, so we can discuss it later but, I think it’s kind of important that the release has a New Year feel to it, rather than a Last Year feel to it. A final release in December is all great, but it’s the holidays now, and I’m not updating until January. When I do that, I don’t want last year’s version. It’s just marketing, of course, but I can’t help but think that’s important. :person_shrugging:

I totally see the holidays problem: I live in Spain where nothing starts again until after the 6th January — but I think an RC in December followed by a final mid-January should be quite relaxed (to the extent that these things can be :sweat_smile:)

2 Likes