change release flow so that moderators needs to merge rather than che… (

#2494)

* change release flow so that moderators needs to merge rather than cherry-picking for releasing

* remove text from BRANCHING-MODEL.md. rename "hf" to "hotfix" in hotfix branch name

* change flow to allow for a faster release

* re-add hotfix flow

BRANCHING-MODEL.md

@@ -3,20 +3,16 @@ This section describes
 - how branches are handled
 - defectdojo release cycle
 
+Please be careful to submit your pull requests to the correct branch: 
+- bugfix: latest  "release/a.b.x" branch (+ merge using a separate PR against the dev branch)
+- evolutions: dev branch
+
+If in doubt please use dev branch.
+
 # Release and hotfix model
 ![Schemas](doc/branching_model.png)
-## Releasing
-- Start a release/x.y.0 release branch off dev branch
-- Commit only bug fixes from `dev` branch onto this branch
-- Dev branch keeps living with further evolutions
-- Every 4-8 weeks, merge the release branch to master and tag x.y.0: this is when the new release is out: x.(y+1).0
-
-# Issuing a hotfix
-- In case of major issue found after releasing, and fixed in `dev`:
-  - Issue a hotfix branch (first is x.y.1) holding this fix
-  - Merge to `master` and the next release branch
 
 
-Diagrams created with https://www.planttext.com
+Diagrams created with https://www.planttext.com/
 
-This model is close to gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow, https://nvie.com/posts/a-successful-git-branching-model/ with the feature branch being made in each contributor repository.
+This model is inspired by https://nvie.com/posts/a-successful-git-branching-model/ with the feature branch being made in each contributor repository.

PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,16 @@
 This template is for your information. Please clear everything when submitting your pull request.
 
-**Note: DefectDojo is now on Python3.6 and Django 2.2.x. Please submit your pull requests to the 'dev' branch as the 'legacy-python2.7' branch is only for bug fixes. Any new features submitted to the legacy branch will be ignored and closed.**
+**Note: DefectDojo is now on Python3.6 and Django 2.2.x.**
+
+**Please submit your pull requests to :**
+
+**- evolutions: dev branch**
+
+**- bugfix: latest "release/x.y.z" branch**
+
+**- hotfixes: master branch**
+
+If in doubt you can use dev branch, it will just roll-out later. 
 
 When submitting a pull request, please make sure you have completed the following checklist:
 

doc/branching_model.puml

@@ -1,68 +1,95 @@
 @startuml
 !pragma teoz true
 
-== Release ==
+== Initial release ==
 participant "Dev branch" as devbranch order 10 #LightBlue
-participant "RC branch" as rcbranch order 20 #YellowGreen
+participant "Release branch" as rlsbranch order 20 #YellowGreen
 participant "Master branch" as master order 30 #99FF99
+participant "Maintainance branch" as maintainbranch order 40 #YellowGreen
 participant "Hotfix branch" as hotbranch order 40 #DarkSalmon
 
-{startrc} devbranch -> rcbranch ++ #YellowGreen: Create branch release/x.y.0
+{startrc} devbranch -> rlsbranch ++ #YellowGreen: Create branch "release/1.0.0"
 
 
 note left of devbranch
   Evolutions
 end note
 
 
-rcbranch <- devbranch: Cherry-pick bug fixes
-rcbranch <- devbranch: Cherry-pick more bug fixes
+note right of rlsbranch
+  Bug fixes
+end note
 
+rlsbranch --> devbranch: Contributors merge bug fixes using a separate PR
 
-note right of rcbranch
-  - Bug fixes
-  - Tag "x.y.0-rcn" on RC branch
-  - Push "x.y.0-rcn" to DockerHub
-end note
 
 
-rcbranch -> master: Merge
+rlsbranch -> master: Merge
 note right of master
     Official release
-    - Tag "x.y.0"
-    - Push "x.y.0" to DockerHub
+    - Tag "1.0.0"
+    - Push "1.0.0" to DockerHub
 end note
 
-{endrc} rcbranch --> devbranch --: Release done
+== Release maintainance ==
+master -> maintainbranch ++ #YellowGreen: Create branch "release/1.0.x"
 
-devbranch -> rcbranch: Create branch release/x.(y+1).0
-note left of devbranch
-  Increase x if case of
-  major breaking change
+note right of maintainbranch
+  Bug fixes
 end note
 
+maintainbranch --> devbranch: Contributors merge bug fixes using a separate PR
 
-... ...
-{startrc} <-> {endrc}: 4-8 weeks
+
+maintainbranch -> master: Merge
+note right of master
+    Official release
+    - Tag "1.0.1"
+    - Push "1.0.1" to DockerHub
+end note
+
+maintainbranch --> devbranch: Contributors merge bug fixes using a separate PR
+
+maintainbranch -> master: Merge
+note right of master
+    Official release
+    - Tag "1.0.2"
+    - Push "1.0.2" to DockerHub
+end note
 
 == Hotfix ==
 
-master -> hotbranch ++ #DarkSalmon: Create short-lived fix branch x.y.z
+master -> hotbranch ++ #DarkSalmon: Create short-lived fix branch "hotfix/1.0.3"
 note left
-z starts at 1. Increase for each hotfix.
+If in need of an urgent fix 
+and PR have already been merged to release/1.0.x
+since 1.0.2 release
 end note
 
 note right of hotbranch
     Severe bug
     to be corrected
 end note
-hotbranch <- devbranch --: Merge hotfix per PR
-hotbranch --> master: Cherry-pick
+
+hotbranch -> maintainbranch: Merge
+hotbranch -> devbranch --: Merge (Optional)
+hotbranch -> master --: Merge
 note right of master
     Official release
-    - Tag "x.y.z" on master
-    - Push "x.y.z" to DockerHub
+    - Tag "1.0.3"
+    - Push "1.0.3" to DockerHub
 end note
-hotbranch --> rcbranch: Cherry-pick
+
+== Next release ==
+{endrc} devbranch -> rlsbranch: Create branch\n "release/1.1.0"
+note left of devbranch
+  Or release/2.0.0 in case of
+  major breaking change
+end note
+
+
+... ...
+{startrc} <-> {endrc}: \n4-8 weeks
+
 
 @enduml