alpaka release strategy

[j-stephan]

In today's developer council we formalized our release strategy for future releases, beginning with release 0.7.

• Planned features are not assigned to specific releases anymore. Instead, new features are committed to the development branch once they are ready.
• We will snapshot the development branch into a release branch two months before the final release to give our users time to test new features and adapt to breaking changes. After the freeze only bug fixes will be permitted in the release branch.
• Once a release candidate is pulled out of the development branch the developer council will jointly review the incorporated changes and write the changelog for the planned release.
• Between releases there will be a time period of four months. In other words, we plan to release thrice a year. Experience will show if this can be sustained in the mid- to long-term. Depending on the results of the provisional schedule we might opt to release more often (four times a year) or less often (twice a year). Additionally, we might skip individual release dates if the number of new features does not permit a new version (decided by the council).
• In general, there will be no feature and compatibility backports (such as new CUDA versions) to previous releases. Exceptions to this rule are voted on by the council.

The release 0.7 is planned for early July 2021 with the feature freeze occurring on 30 April 2021. This gives us the following timetable for the foreseeable future:

Version	Feature freeze	Release date
0.7	2021-04-30	2021-07-01
0.8	2021-08-31	2021-11-01
0.9	2021-12-31	2022-03-01
1.0 (?, TBD)	2022-04-30	2022-07-01