diff --git a/README/ReleaseNotes/v642/index.md b/README/ReleaseNotes/v642/index.md
index 0cde4d2caf113..07c1bd1b6e63f 100644
--- a/README/ReleaseNotes/v642/index.md
+++ b/README/ReleaseNotes/v642/index.md
@@ -153,6 +153,19 @@ Replace `obj.Connect(signal, "TPyDispatcher", disp, "Dispatch()")` with
 
 * Reading a collection without its dictionary no longer crashes when the elements hold a `std::string` or a `TString`. The emulated collection proxy relocated its elements with a raw memory copy when its buffer had to grow, which corrupts an object that points into itself, such as a `std::string` using the small string optimization; the invalid pointer was then freed when the object was destroyed. Such elements are now destroyed and reconstructed at the new location instead. This affected for instance a `std::vector<std::pair<std::string,double>>` read back without a dictionary.
 
+### RNTupleProcessor
+
+The RNTupleProcessor is a new, standalone interface for creating *chains* (similar to TTree's `TChain`) and *joins* (similar to TTree friends) from RNTuples in a composable way, and iterating over their entries.
+Until this release, it was available in the experimental namespace.
+With ROOT v6.42:
+
+* The RNTupleProcessor for single RNTuples and chained RNTuples has moved out of `ROOT::Experimental`.
+They can be created with `ROOT::RNTupleProcessor::Create()` and `ROOT::RNTupleProcessor::CreateChain()`, respectively.
+Processing joined RNTuples will remain available in the experimental namespace for this release, in order to address a few additional (potentially interface-breaking) improvements.
+Creating an RNTupleProcessor for joins can (for now) be done by calling `ROOT::Experimental::CreateRNTupleJoinProcessor`.
+* An experimental RDataFrame datasource using the RNTupleProcessor has been added.
+RDataFrames can be created from an existing RNTupleProcessor by calling `ROOT::Experimental::RDF::FromRNTupleProcessor()`.
+
 ## Core
 
 * `TClass::IsTriviallyRelocatable()` reports whether an object of a class can be moved to a new address with a raw memory copy, i.e. without running a move or copy constructor (trivial relocatability in the C++26 sense). It is backed by the new `kClassIsTriviallyRelocatable` class property, which `TInterpreter::ClassInfo_ClassProperty()` now fills in. A class the interpreter does not know about, in particular an emulated one, is conservatively reported as not relocatable.