docs: improve gitflow model for supported versions

[ncoden]

Description

Currently, supported versions are hosted on support/<version>. This branch is intended to receive all commits and pull requests for compatible patches in order to prepare a release. The release would be made on the same branch.

The issue with this model is that unline latest versions, support versions are not released on a "safe" branch. In order to resolve this issue and harmonize the way versions are prepared and released, the current commit move support/<version> to develop/<version> and add master/<version>.

Changes:

• Update CONTRIBUTING documentation to describe the develop/...+master/... approach
• Update GitHub pull request template to advise develop/... instead

Types of changes

• Documentation
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing
  functionality to change)

Checklist (all required):

• I have read and follow the CONTRIBUTING document.
• There are no other pull request similar to this one.
• The pull request title is descriptive.
• The template is fully and correctly filled.
• The pull request targets the right branch (develop or support/*).
• My commits are correctly titled and contain all relevant information.
• My code follows the code style of this project.
• I have updated the documentation accordingly to my changes (if relevant).
• I have added tests to cover my changes (if relevant).
• All new and existing tests passed.

[DanielRuf]

Hm, not sure if master/version makes sense.
At work we have master, develop and feature/hotfix branches.
At magento we have 2.2-develop, 2.3-develop, 2.2, 2.3 and so on.

In general there should be only one master branch imho option, except we support multiple releases at the same time (6.5, 6.6).

[ncoden]

My concern is that support releases (like v6.5.1) should be made on a stable branch, for exactly the same reasons as for standard releases. develop and master are both relative to the latest developing/released version and I think that patches for older versions require their dedicated branches too.

[ncoden]

except we support multiple releases at the same time (6.5, 6.6)

This is the point. v6.5.1 can come after v6.6.0 and cannot use master as a stable release bramch.

[ncoden]

Hi @DanielRuf could you give me your opinon on this ? I need it to prepare the v6.5.0-rc.2 release on the correct branch.