chore(release): update release cycles guidelines

From discussion eclipse-sw360/sw360#2692

Signed-off-by: Gaurav Mishra <mishra.gaurav@siemens.com>

content/en/docs/Development/Dev-DoD-and-Style.md

@@ -8,9 +8,11 @@ description: "The definition of done helps to set a common understanding for sol
 ### Policy
 
 * Review points should involve one person from another angle (not just the person you were sitting together with anyways)
+* No self merging of pull requests
 * Limit items in review to 5, try to coordinate 
 * Using Github assignments to issues or pull requests
 * Open review items require conversation
+* Every change must be proposed in the form of a pull request (no commits to main without review)
 
 # Definition of Done
 
@@ -25,7 +27,7 @@ description: "The definition of done helps to set a common understanding for sol
 * Avoid (serious) compiler warnings
   * Squash your commits into one or more logical units of work. No dozens of hourly/daily commits in your pull request, please
   * Rebase onto current master so that a fast forward merge is possible
-  * That means that merge to master is prepared
+  * That means that merge to main is prepared
 
 * No breaking test
   * Unit testing as it is already present
@@ -35,7 +37,7 @@ description: "The definition of done helps to set a common understanding for sol
   * For new / added functionality
 
 * Documentation
-  * in the Githuib Wiki-Section, if you have done something new
+  * In the GitHub Wiki-Section, if you have done something new
   * At least a technical note for newly added functionality
 
 * Commit style
@@ -46,22 +48,15 @@ description: "The definition of done helps to set a common understanding for sol
 
 Review basically checks for the D-o-D items, in particular
 
-* Code style, not really formatting, but issues like style attributes in HTML tags or exception handling useful
+* Code style, not really formatting, but issues like style attributes in HTML tags or exception handling useful.
 * Design / architecture issues
 * Community contribution suitability
 * Issue coverage (does it actually solve the problem?)
-* Add to commit message of merge commit explicitly:
-```
-review-by:email@domain.com
-```
-and
-```
-tested-by:email@domain.com
-```
 
 # Licensing and File Header
 
-All files contributed require headers - this will ensure the license and copyright clearing at the end. Also, all contributions must have the same license as the original source.
+All files contributed require headers - this will ensure the license and copyright clearing at the end. Also, all
+contributions must have the same license as the original source.
 
 If a file has relevant functionality, note that we should move to Eclipse 2.0
 
@@ -71,12 +66,12 @@ If a file has relevant functionality, note that we should move to Eclipse 2.0
  * Copyright NEXT COPYRIGHT HOLDER, 2017.
  * Part of the SW360 Portal Project.
  *
- * SPDX-License-Identifier: EPL-1.0
+ * SPDX-License-Identifier: EPL-2.0
  *
  * All rights reserved. This program and the accompanying materials
- * are made available under the terms of the Eclipse Public License v1.0
+ * are made available under the terms of the Eclipse Public License v2.0
  * which accompanies this distribution, and is available at
- * http://www.eclipse.org/legal/epl-v10.html
+ * http://www.eclipse.org/legal/epl-v20.html
  */
 ```
 (please adapt comment characters usage)
@@ -94,4 +89,5 @@ For small files such as property files, configuration files or standard XML file
 
 # Code style
 
-Just use the standard Java formatting rules of your IDE and **do not reformat** code from others, because you like to correct formatting of other's code.
+Just use the standard Java formatting rules of your IDE and **do not reformat** code from others, because you like to
+correct formatting of other's code.

content/en/docs/Development/Dev-Releasing-SW360.md

@@ -11,7 +11,7 @@ We have the following main principles for versioning and releases. We consider [
 >
 > - MAJOR version when you make incompatible API changes,
 > - MINOR version when you add functionality in a backwards-compatible manner, and
-> - PATCH version when you make backwards-compatible bug fixes.
+> - PATCH version when you make backwards-compatible bug fixes or security fixes.
 >
 > Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
 
@@ -20,27 +20,51 @@ with the following implementation in our project:
 ### Major Version
 
 * API breaking changes are considered for the upcoming REST API.
-* Breaking change is *also* if a migration script is required for the data base.
+* Breaking change is *also* if a migration script is required for the database.
 * Thrift API is not considered a public API anymore.
-* Therefore milestones cannot correspond to our versions like `1.4`, `1.5`, etc. anymore: we do not know which feature or issue will cause a version jump according to semantic versioning guidelines.
+* Therefore, milestones cannot correspond to our versions like `1.4`, `1.5`, etc. anymore: we do not know which feature
+  or issue will cause a version jump according to semantic versioning guidelines.
+* While preparing for a new major release, the repository should go into freeze mode:
+  * No new features can be merged.
+  * No dependency updates.
+  * Add decided bug fixes/issues closed.
+  * The main branch is stable and tested.
+  * **Only exception** for the freeze are security vulnerability fixes.
 
 ### Minor Version
 
-* Changes to the thrift API will cause minor version increment.
 * Larger new functionality which is backwards compatible, maybe one pull requests or maybe a group of pull requests.
+* New functionality should come with appropriate test cases either in code (unit or functional) or in the
+  [TestCases document]({{< relref path="TestCases">}}).
 * Minor versions requires also tagging in the repo.
 
 ### Patch Level
 
-* Every push (merged pull request) to master shall generate *at least* (not there yet) a new patch level version, in order to allow for (clean) deployments at this level.
-* Could e also minor improvements like adding a button with some functionality
-* Patch level is not tagged.
+* Minor improvements which are backwards compatible and does not require a migration (qualifies as a breaking change).
+* A group of pull requests updating outdated dependencies (at least a minor version update of dependency).
+* Pull request merge which closes a GitHub issue.
+
+### Release code freeze cycle
+
+* **Major release:** A strict code freeze cycle to be followed with an expected release date.
+  * During the freeze cycle, no other pull request to be merged unless it fixes/closes decided issue.
+  * New test cases can always be merged.
+  * Dependencies are frozen at the announcement of expected release date.
+  * Exceptions to update a dependency:
+    * **Major vulnerability:** Must be updated even if the release date needs to be shifted.
+    * **Medium vulnerability:** Test the update, if validated, merge. If it can't be validated in reasonable period, the
+      decision on what to do goes to core team.
+    * **Minor vulnerability:** Can be merged only if it does not break compatibility, otherwise not be updated.
+* **Minor release:** The code freeze can be relaxed and a release date is not expected.
+  * No new **major** feature to be added or changed.
+  * Minor bug fixes/patches can be merged.
+  * Dependencies can be updated.
+  * If a dependency update breaks a minor release, a patch release to be created with the fix.
+* **Patch release:** No code freeze for patch release.
 
 ## Naming and Meaning of Milestones
 
-* Milestones cannot correspond to versions (releases) anymore, because in general the version designator is determined by the level of change.
-* We use milestones as work packages. We see them as work packages from an organizational point of view. However, it is not a milestone to release a version, because - again in general - the version is determined by the level of change.
-* However, If the last merged pull quest of a work package, a completing merge: If it is not causing a major or minor version increment, still, this would lead to a minor version increment.
+* We are no longer following milestones in favour of simple semantic versioning.
 
 ## Technical Implementation
 
@@ -49,46 +73,37 @@ with the following implementation in our project:
 
 # Technical: Maven Universe How to make/tag a release⁽¹⁾:
 
-The following information refers to the existing maven-based versioning scheme, as of now we are looking into a system which is not leading to a temporary change in the repo, commit, and then reverting changes.
+The following information refers to the existing maven-based versioning scheme, as of now we are looking into a system
+which is not leading to a temporary change in the repo, commit, and then reverting changes.
 
-Let us assume, that we want to tag the version **1.2.0** and that the current version in the pom's is **1.2.0-SNAPSHOT**.
+Let us assume, that we want to tag the version **1.2.0** and that the current version in the pom.xml is **1.1.13**.
 
 ### 0. Work in a clean environment
-Especially should all poms be without uncommitted changes. The safe way is to start with:
-``` Bash
+Especially all poms should be without uncommitted changes. The safe way is to start with:
+```shell
 $ cd /tmp/
-$ git clone https://github.com/eclipse/sw360.git
-$ cd sw360portal
+$ git clone https://github.com/eclipse-sw360/sw360.git
+$ cd sw360
 ``` 
 
 ### 1. Write the version of the release into the poms
 <pre>
 $ mvn versions:set -DnewVersion=<b>1.2.0</b>
-$ git add pom.xml \*\*/pom.xml
-$ git commit -m "set version to <b>1.2.0</b>"
+$ git add pom.xml **/pom.xml
+$ git commit -sS -m "chore(release): set version to <b>1.2.0</b>"
 </pre>
-This will actually edit all pom.xml files and change the versions to **1.2.0**, i.e. remove the SNAPSHOT.
+This will actually edit all pom.xml files and change the versions to **1.2.0**.
 
 ### 2. Test the project
-<pre>
+```shell
 $ mvn install
-</pre>
-or even better: use vagrant.
+```
 
 ### 3. Create and push the tag
-```Bash
+```shell
 $ mvn scm:tag
 ```
-This creates the tag and **pushes it to github**.
-
-### 4. Write the new incremented SNAPSHOT-version into the poms
-```Bash
-$ mvn versions:set -DnewVersion=<b>1.3.0-SNAPSHOT</b>
-$ git add pom.xml \*\*/pom.xml
-$ git commit -m "set version to <b>1.3.0-SNAPSHOT</b>"
-$ git push origin master
-```
-
+This creates the tag and **pushes it to GitHub**.
 
 --
 ⁽¹⁾ based on: https://axelfontaine.com/blog/final-nail.html