blob: 3f3a8ee3bb83add9fd8b86082893e9144174532a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
Release Process
===============
Versioning
----------
Since version 1.0, Patchwork has implemented a version of `Semantic
Versioning`__ . To summarise, releases take the format **MAJOR.MINOR.PATCH**
(or just **MAJOR.MINOR**). We increment:
1. **MAJOR** version when we make major UI changes or functionality updates
2. **MINOR** version when we make minor UI changes or functionality updates
3. **PATCH** version when we make make bug fixes, dependency updates etc.
In Git, each release will have a tag indicating the version number. In
addition, each release series has it's own branch called `stable/MAJOR.MINOR`
to allow backporting of bugfixes or security updates to older versions.
__ http://semver.org/
Release Cycle
-------------
There is no cadence for releases: they are made available as necessary.
Supported Versions
------------------
Typically all development should occur on `master`. While we will backport
bugfixes and security updates, we will not backport any new features. This is
to ensure stability for users of these versions of Patchwork.
Release Checklist
-----------------
* Documentation has been updated with latest release version
* Documentation references latest supported version of Django
Backporting
-----------
We will occasionally backport bugfixes and security updates. When backporting a
patch, said patch should first be merged into `master`. Once merged, you can
backport by cherry-picking commits, using the `-x` flag for posterity:
.. code-block:: shell
$ git cherry-pick <master_commit> -x
There may be some conflicts; resolve these, uncommenting the `Conflicts` line
when commiting::
Conflicts
patchwork/bin/pwclient
When enough patches have been backported, you should release a new `PATCH`
release.
|