Changes between Initial Version and Version 1 of Version4.2Roadmap

May 11, 2022, 1:58:14 AM (2 years ago)
Mariusz Felisiak



  • Version4.2Roadmap

    v1 v1  
     5Django 4.2 Roadmap
     8This document details the schedule and roadmap towards Django 4.2.
     10What features will be in Django 4.2?
     13Whatever gets committed by the alpha feature freeze!
     15Django 4.2 will be a time-based release. Any features completed and committed
     16to main by the alpha feature freeze deadline noted below will be included. Any
     17that miss the deadline won't.
     19If you have a major feature you'd like to contribute, please introduce yourself
     20on the `django-developers mailing list <!forum/django-developers>`_
     21so you can find a shepherd for your feature.
     23Minor features and bug fixes will be merged as they are completed. If you
     24have submitted a patch, be sure the flags on the Trac ticket are correct such
     25that it appears in the "Patches needing review" filter of the `Django Development Dashboard <>`_. Better yet,
     26find someone to review your patch and mark the ticket as "Ready for checkin".
     27Tickets marked "Ready for checkin" are regularly reviewed by mergers.
     32Major milestones along the way to 4.2 are scheduled below. See `Process`_,
     33below, for more details. The dates are subject to change as necessary.
     35==================  ======================================================
     36January 16, 2023        Django 4.2 alpha; feature freeze.
     38February 20             Django 4.2 beta; non-release blocking bug fix freeze.
     40March 20             Django 4.2 RC 1; translation string freeze.
     42April 3             Django 4.2 final
     43==================  ======================================================
     48Any features not completed by the feature freeze date won't make it into 4.2.
     50Mariusz Felisiak as the release manager, will be in charge of keeping the
     51schedule. The release manager keeps track of who's working on what issues so
     52that bug reports can be efficiently routed and also nag developers who are in
     53danger of missing deadlines.
     55Feature freeze / Alpha 1
     58All major and minor features must be merged by the Alpha 1 deadline. Any
     59features not done by this point will be deferred or dropped. At this time, we
     60will fork ``stable/4.2.x`` from ``main``.
     62After the alpha, non-release blocking bug fixes may be backported at the
     63mergers' discretion.
     65Beta 1
     68Beta 1 marks the end of any changes that aren't considered release blocking
     69bugs. A bug is a "Release blocker" if it's a regression from a previous version
     70of Django or if it's an important bug in a new feature. Only release blocking
     71bug fixes will be allowed to be backported after the beta.
     73RC 1
     76If there is still a consistent stream of release blockers coming in at the
     77planned release candidate date; we'll release beta 2 to encourage further
     78testing and push the release candidate date out ~1 month.
     80RC 1 marks the freeze for translation strings; translators will have two weeks
     81to submit updated translations for inclusion in the final release. Release
     82blocking bug fixes may continue to be backported.
     87Ideally, Django 4.2 final will ship two weeks after the last RC. If there are
     88no major bugs found by 2 weeks after the release candidate, we will issue 4.2
     89final. If not, we will decide how to proceed from there at that time (likely
     90another release candidate would be issued at some point).
     92How you can help
     95The only way we'll meet these deadlines is with a great deal of community effort.
     96To that end, here's how you can help:
     98* Read the `guide to contributing to Django <>`_ and the `guide to Django's
     99  release process <>`_.
     101  These guides explain how our process works. where to ask questions,
     102  etc. It'll save everyone time if we're all on the same page when it comes to process.
     104* Work on patches and `triage tickets <>`_.
     106* Attend a sprint (in person or in IRC).
     108* Test the release snapshots (alphas, betas) against your code and report bugs.
     110* We need *lots* of testers if we're to have a bug-free release. Download a snapshot or a git checkout and give it a try!
Back to Top