@@ -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" pull request. Before merging that pull
62+ request, a branch is created off of main to track the previous feature release.
63+ For example, the 5.1.x branch is created shortly after the release of Django
64+ 5.2, and main starts tracking the Django 5.2.x series.
0 commit comments