ci: make development in develop branch possible (#206)

This PR proposes to use `develop` branch as a development branch keeping
`main` branch stable in case of necessary bug fixes.

The proposed flow (documented in the README as well):

* we make our development in `develop` branch
* once we are ready to release, we make a PR from `develop` to `main`
branch, after the merge new tags will be created from the main `branch`
* go to first step in this list

In case we need to release a bug fix - we can create a PR to main, merge
it, new tags will be created, issue is solved and we can cherry-pick
this commit to the `develop` branch. The similar scenario is working in
the UCC repository right now and the results are quite good.

We can go even further and make a develop branch a default one in this
GitHub repository.

This PR removes existing pre-release from the develop branch -> we don't
want to confuse tags with the ones which will be released from `main`
branch. And essentially it is not necessary to have a release from
develop.

.github/workflows/build-test-release.yaml

@@ -1,6 +1,5 @@
 name: "build-test-release"
 on:
-  workflow_dispatch:
   push:
     branches:
       - "main"
@@ -33,7 +32,7 @@ jobs:
         with:
           python-version: "3.7"
       - run: |
-          bash <(curl https://raw.githubusercontent.com/rhysd/actionlint/v1.6.24/scripts/download-actionlint.bash)
+          bash <(curl https://raw.githubusercontent.com/rhysd/actionlint/v1.6.26/scripts/download-actionlint.bash)
       - uses: pre-commit/[email protected]
 
   publish:

.licenserc.yaml

@@ -24,5 +24,3 @@ header:
     - "README.md"
     - "LICENSE"
     - ".*"
-
-  comment: on-failure

.releaserc

@@ -17,8 +17,7 @@
   branches:
     [
       "+([0-9])?(.{+([0-9]),x}).x",
-      "main",
-      { name: "develop", prerelease: "beta", channel: "beta" },
+      "main"
     ],
   plugins:
     [

README.md

@@ -6,6 +6,23 @@ Workflow is used by add-ons created and managed by [addonfactory repository temp
 
 Workflow defines jobs which perform security code scanning, execute different types of tests, build add-on package and make a GitHub release.
 
+## Development flow
+
+* All the changes should first go to the `develop` branch (using "squash commit"), `main` branch should contain stable code
+* Official releases are made from `main` branch (when it's time to rollout new template changes):
+  * create a PR from `develop` to `main`
+  * test it
+  * get all the approvals from the team
+  * then merge it using "merge commit" option
+* If bugfix release is needed:
+  * make a change
+  * test it
+  * create a PR to the `main` branch
+  * get all the approvals from the team
+  * merge it using "merge commit" option
+  * backport the change back to the `develop` branch
+  * new version of the workflow is going to be released (v4.17.0 (before) -> v4.17.1 (after)) and it will automatically applied to all the repositories
+
 # Troubleshooting for different workflow stages in GitHub Actions
 
 ## General troubleshooting