[SYCL] Add guidelines for working on release branches (intel#17042)

Author: AlexeySachkov

sycl/ReleaseNotes.md

@@ -1,3 +1,21 @@
+# Release notes for an upcoming release (dates TBD)
+
+## New Features
+
+- Added support for ... intel/llvm#pr
+
+## Improvements
+
+- Improved handling of ... intel/llvm#pr
+
+## Bug Fixes
+
+- Fixed ... intel/llvm#pr
+
+## Misc
+
+- Did this and that ... intel/llvm#pr
+
 # Release notes Nov'24
 
 Release notes for commit range

sycl/doc/developer/ContributeToDPCPP.md

@@ -37,6 +37,36 @@ For any DPC++-related commit, the `[SYCL]` tag should be present in the
 commit message title. To a reasonable extent, additional tags can be used
 to signify the component changed, e.g.: `[UR]`, `[CUDA]`, `[Doc]`.
 
+## Release notes
+
+You are encouraged to record your change into
+[release notes](https://github.com/intel/llvm/blob/sycl/sycl/ReleaseNotes.md)
+under "Release notes for an upcoming release" section.
+
+A change should be noted there when:
+
+- A public interface (API, command line options, env variables, etc.) is being
+  changed
+- A bug is being fixed
+- Any change is being made which has an observable behavior (including
+  performance)
+
+A change should **not** be noted there when:
+
+- It has no functional or performance impact
+- It is about our CI infrastructure, testing infrastructure, or tests
+
+There are no strict guidelines on how to structure release notes, but for
+consistency it is better to follow the existing structure minimal changes. The
+structure we have been using so far is split by change type (i.e. new
+features and bug fixes) and then sub-split by component (i.e. compiler,
+runtime). Please use past tense when describing your change and leave a
+reference to your PR using `intel/llvm#NNNNN` syntax. If you want to reference
+an in-tree document (like an extension spec, for example), it must be
+referenced using a permalink so that it stays actual even if document is moved.
+
+When in doubt, you can always ask reviewers for help/guidance/suggestions.
+
 ## Using \<iostream\> 
 
 According to 

sycl/doc/developer/WorkingOnAReleaseBranch.md

@@ -0,0 +1,41 @@
+# Working on a release branch
+
+A "release branch" is defined as a branch whose name starts with `sycl-rel-`
+prefix.
+
+Those branches are intended to indicate stable snapshots of our product so that
+our users don't need to guess which nightly build is good enough for their
+needs.
+
+Therefore, those branches have higher quality requirements and as such have
+different contribution rules intended to preserve their stability.
+
+If you are not familiar with the [general contribution guidelines][contributing]
+or the [DPC++ specific contribution guidelines][contributing-to-dpcpp], please
+familiarize yourself with those documents first because they also apply to
+release branches.
+
+## Extra rules for release branches
+
+### Only cherry-picks are allowed
+
+It is assumed that everything you do on a release branch should also be
+repeated on the default `sycl` branch to ensure that it is automatically
+included into future releases.
+
+Therefore, when submitting a PR to a release branch, its description should
+contain a link to the corresponding PR in the default `sycl` branch.
+
+Note that it is not acceptable to first merge something into a
+release branch and then apply it to the default `sycl` branch. The flow goes in
+the opposite direction where you first land a patch to the default `sycl` branch
+and then backport it to a release branch.
+
+### No new features are allowed
+
+Features are generally more complicated than bug fixes and may require further
+bug fixes as well. Considering that release branches are intended to be stable,
+no new features are allowed to be added there.
+
+[contributing]: https://github.com/intel/llvm/blob/sycl/CONTRIBUTING.md
+[contributing-to-dpcpp]: ./ContributeToDPCPP.md

sycl/doc/index.rst

@@ -67,3 +67,4 @@ Developer Documentation
    developer/ABIPolicyGuide
    developer/ContributeToDPCPP
    developer/KHRExtensions
+   developer/WorkingOnAReleaseBranch