@@ -23,3 +23,42 @@ open an issue in our issue tracker, JIRA:
2323   the issue and the steps to reproduce it.
2424
2525Bug reports in JIRA for this project can be viewed by everyone.
26+ 
27+ .. _supported-versions-policy :
28+ 
29+ Supported versions
30+ ================== 
31+ 
32+ Django MongoDB Backend follows Django's :ref: `supported versions policy 
33+ <django:supported-versions-policy>`.
34+ 
35+ The main development branch of Django MongoDB Backend follows the most recent
36+ :term: `django:feature release ` of Django and gets all new features and
37+ non-critical bug fixes.
38+ 
39+ Security fixes and data loss bugs will also be applied to the previous feature
40+ release branch, and any other supported long-term support release branches.
41+ 
42+ As a concrete example, consider a moment in time between the release of Django
43+ 5.2 and 6.0. At this point in time:
44+ 
45+ - Features will be added to the main branch, to be released as Django 5.2.x.
46+ 
47+ - Critical bug fixes will also be applied to the 5.1.x branch and released as
48+   5.1.x, 5.1.x+1, etc.
49+ 
50+ - Security fixes and bug fixes for data loss issues will be applied to main,
51+   5.1.x, and any active LTS branches (e.g. 4.2.x, if Django MongoDB Backend
52+   supported it). They will trigger the release of 5.2.x, 5.1.y, 4.2.z.
53+ 
54+ .. _branch-policy :
55+ 
56+ Branch policy
57+ ============= 
58+ 
59+ After a new Django :term: `django:feature release ` (5.2, 6.0, 6.1 etc.), Django
60+ MongoDB Backend's main branch starts tracking the new version following the
61+ merge of a "Add support for Django X.Y" PR. Before merging that PR, a branch is
62+ created off of main to track the previous feature release version. For example,
63+ the 5.1.x branch is created shortly after the release of Django 5.2, and main
64+ starts tracking the Django 5.2.x series.
0 commit comments