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

05/13/2020 07:38:07 AM (10 months ago)
Carlton Gibson

Created Version 3.2. Roadmap


  • Version3.2Roadmap

    v1 v1  
     5Django 3.2 Roadmap
     8This document details the schedule and roadmap towards Django 3.2.
     10What features will be in Django 3.2?
     13Whatever gets committed by the alpha feature freeze!
     15Django 3.2 will be a time-based release. Any features completed and committed
     16to master by the alpha feature freeze deadline noted below will be included.
     17Any that 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
     21<!forum/django-developers>`_ so you can find a
     22shepherd for your feature.
     24Minor features and bug fixes will be committed as they are completed. If you
     25have submitted a patch, be sure the flags on the Trac ticket are correct such
     26that it appears in the "Patches needing review" filter of the `Django
     27Development Dashboard <>`_. Better yet,
     28find someone to review your patch and mark the ticket as "Ready for checkin".
     29Tickets marked "Ready for checkin" are regularly reviewed by committers.
     34Major milestones along the way to 3.2 are scheduled below. See `Process`_,
     35below, for more details. The dates are subject to change as necessary.
     37=================  ======================================================
     38January 14, 2021   Django 3.2 alpha; feature freeze.
     40February 18        Django 3.2 beta; non-release blocking bug fix freeze.
     42March 18           Django 3.2 RC 1; translation string freeze.
     44April 1            Django 3.2 final
     45=================  ======================================================
     50Any features not completed by the feature freeze date won't make it into 3.2.
     52Carlton Gibson as the release manager, will be in charge of keeping the
     53schedule. The release manager keeps track of who's working on what issues so
     54that bug reports can be efficiently routed and also nag developers who are in
     55danger of missing deadlines.
     57Feature freeze / Alpha 1
     60All major and minor features must be committed by the Alpha 1 deadline. Any
     61features not done by this point will be deferred or dropped. At this time, we
     62will fork ``stable/3.2.x`` from ``master``.
     64After the alpha, non-release blocking bug fixes may be backported at the
     65committer's discretion.
     67Beta 1
     70Beta 1 marks the end of any changes that aren't considered release blocking
     71bugs. A bug is a "Release blocker" if it's a regression from a previous version
     72of Django or if it's an important bug in a new feature. Only release blocking
     73bug fixes will be allowed to be backported after the beta.
     75RC 1
     78If there is still a consistent stream of release blockers coming in at the
     79planned release candidate date; we'll release beta 2 to encourage further
     80testing and push the release candidate date out ~1 month.
     82RC 1 marks the freeze for translation strings; translators will have two weeks
     83to submit updated translations for inclusion in the final release. Release
     84blocking bug fixes may continue to be backported.
     89Ideally, Django 3.2 final will ship two weeks after the last RC. If there are
     90no major bugs found by 2 weeks after the release candidate, we will issue 3.2
     91final. If not, we will decide how to proceed from there at that time (likely
     92another release candidate would be issued at some point).
     94How you can help
     97The only way we'll meet these deadlines is with a great deal of community effort.
     98To that end, here's how you can help:
     100* Read the `guide to contributing to Django <>`_ and the `guide to Django's
     101  release process <>`_.
     103  These guides explain how our process works. where to ask questions,
     104  etc. It'll save everyone time if we're all on the same page when it comes to process.
     106* Work on patches and `triage tickets <>`_.
     108* Attend a sprint (in person or in IRC).
     110* Test the release snapshots (alphas, betas) against your code and report bugs.
     112* 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