[SYCL] Add guidelines for working on release branches

Author: AlexeySachkov

sycl/ReleaseNotes.md

@@ -1,3 +1,21 @@
+# Release notes for an upcoming release (dates TBD)
+
+## New Features
+
+- Added suport 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 Jul'24
 
 Release notes for commit range

sycl/doc/developer/ContributeToDPCPP.md

@@ -37,6 +37,33 @@ 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 (but it is not required) to record your change into
+[release notes](/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 and 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 without disrupting it
+much. 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.
+
+When in doubt, you can always ask reviewers for help/guidance/suggestions.
+
 ## Using \<iostream\> 
 
 According to 

sycl/doc/developer/WorkingOnAReleaseBranch.md

@@ -0,0 +1,39 @@
+# Working on a release branch
+
+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 our 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 [general contribution guidelines][contributing] or
+[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 main 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 main `sycl` branch.
+
+Note that it is not acceptable to first merge something into a
+release branch and then apply it to the main `sycl` branch. The flow goes in
+the opposite direction where you first land a patch to the main branch and then
+backport it to a release branch.
+
+### No new features are allowed
+
+Features are generally more complicated then 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]: /llvm/CONTRIBUTING.md
+[contributing-to-dpcpp]: /sycl/doc/developer/ContributeToDPCPP.md