| 1 | | {{{ |
| 2 | | #!text/x-rst |
| 3 | | |
| 4 | | ================== |
| 5 | | Django 3.2 Roadmap |
| 6 | | ================== |
| 7 | | |
| 8 | | This document details the schedule and roadmap towards Django 3.2. |
| 9 | | |
| 10 | | What features will be in Django 3.2? |
| 11 | | ===================================== |
| 12 | | |
| 13 | | Whatever gets merged by the alpha feature freeze! |
| 14 | | |
| 15 | | Django 3.2 will be a time-based release. Any features completed and merged |
| 16 | | to master by the alpha feature freeze deadline noted below will be included. |
| 17 | | Any that miss the deadline won't. |
| 18 | | |
| 19 | | If you have a major feature you'd like to contribute, please introduce yourself |
| 20 | | on the `django-developers mailing list |
| 21 | | <https://groups.google.com/forum/#!forum/django-developers>`_ so you can find a |
| 22 | | shepherd for your feature. |
| 23 | | |
| 24 | | Minor features and bug fixes will be merged as they are completed. If you |
| 25 | | have submitted a patch, be sure the flags on the Trac ticket are correct such |
| 26 | | that it appears in the "Patches needing review" filter of the `Django |
| 27 | | Development Dashboard <https://dashboard.djangoproject.com/>`_. Better yet, |
| 28 | | find someone to review your patch and mark the ticket as "Ready for checkin". |
| 29 | | Tickets marked "Ready for checkin" are regularly reviewed by mergers. |
| 30 | | |
| 31 | | Schedule |
| 32 | | ======== |
| 33 | | |
| 34 | | Major milestones along the way to 3.2 are scheduled below. See `Process`_, |
| 35 | | below, for more details. The dates are subject to change as necessary. |
| 36 | | |
| 37 | | ================= ====================================================== |
| 38 | | January 14, 2021 Django 3.2 alpha; feature freeze. |
| 39 | | |
| 40 | | February 18 Django 3.2 beta; non-release blocking bug fix freeze. |
| 41 | | |
| 42 | | March 18 Django 3.2 RC 1; translation string freeze. |
| 43 | | |
| 44 | | April 6 Django 3.2 final |
| 45 | | ================= ====================================================== |
| 46 | | |
| 47 | | Process |
| 48 | | ======= |
| 49 | | |
| 50 | | Any features not completed by the feature freeze date won't make it into 3.2. |
| 51 | | |
| 52 | | Carlton Gibson as the release manager, will be in charge of keeping the |
| 53 | | schedule. The release manager keeps track of who's working on what issues so |
| 54 | | that bug reports can be efficiently routed and also nag developers who are in |
| 55 | | danger of missing deadlines. |
| 56 | | |
| 57 | | Feature freeze / Alpha 1 |
| 58 | | ------------------------ |
| 59 | | |
| 60 | | All major and minor features must be merged by the Alpha 1 deadline. Any |
| 61 | | features not done by this point will be deferred or dropped. At this time, we |
| 62 | | will fork ``stable/3.2.x`` from ``master``. |
| 63 | | |
| 64 | | After the alpha, non-release blocking bug fixes may be backported at the |
| 65 | | mergers' discretion. |
| 66 | | |
| 67 | | Beta 1 |
| 68 | | ------ |
| 69 | | |
| 70 | | Beta 1 marks the end of any changes that aren't considered release blocking |
| 71 | | bugs. A bug is a "Release blocker" if it's a regression from a previous version |
| 72 | | of Django or if it's an important bug in a new feature. Only release blocking |
| 73 | | bug fixes will be allowed to be backported after the beta. |
| 74 | | |
| 75 | | RC 1 |
| 76 | | ---- |
| 77 | | |
| 78 | | If there is still a consistent stream of release blockers coming in at the |
| 79 | | planned release candidate date; we'll release beta 2 to encourage further |
| 80 | | testing and push the release candidate date out ~1 month. |
| 81 | | |
| 82 | | RC 1 marks the freeze for translation strings; translators will have two weeks |
| 83 | | to submit updated translations for inclusion in the final release. Release |
| 84 | | blocking bug fixes may continue to be backported. |
| 85 | | |
| 86 | | Final |
| 87 | | ----- |
| 88 | | |
| 89 | | Ideally, Django 3.2 final will ship two weeks after the last RC. If there are |
| 90 | | no major bugs found by 2 weeks after the release candidate, we will issue 3.2 |
| 91 | | final. If not, we will decide how to proceed from there at that time (likely |
| 92 | | another release candidate would be issued at some point). |
| 93 | | |
| 94 | | How you can help |
| 95 | | ---------------- |
| 96 | | |
| 97 | | The only way we'll meet these deadlines is with a great deal of community effort. |
| 98 | | To that end, here's how you can help: |
| 99 | | |
| 100 | | * Read the `guide to contributing to Django <http://docs.djangoproject.com/en/dev/internals/contributing/>`_ and the `guide to Django's |
| 101 | | release process <http://docs.djangoproject.com/en/dev/internals/release-process/>`_. |
| 102 | | |
| 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. |
| 105 | | |
| 106 | | * Work on patches and `triage tickets <https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/>`_. |
| 107 | | |
| 108 | | * Attend a sprint (in person or in IRC). |
| 109 | | |
| 110 | | * Test the release snapshots (alphas, betas) against your code and report bugs. |
| 111 | | |
| 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! |
| 113 | | }}} |
| | 1 | Full details at https://www.djangoproject.com/download/3.2/roadmap/ |