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