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