@@ -23,3 +23,42 @@ open an issue in our issue tracker, JIRA:
23
23
the issue and the steps to reproduce it.
24
24
25
25
Bug 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