[DOC-12898]: Release note for 7.6.5

modules/release-notes/pages/relnotes.adoc

@@ -3,6 +3,8 @@
 :description: Couchbase Server 7.6.x introduces multiple new features and fixes, as well as some deprecations and removals.
 :page-toclevels: 2
 
+include::partial$docs-server-7.6.5-release-note.adoc[]
+
 include::partial$docs-server-7.6.4-release-note.adoc[]
 
 include::partial$docs-server-7.6.3-release-note.adoc[]

modules/release-notes/partials/docs-server-7.6.5-release-note.adoc

@@ -0,0 +1,83 @@
+== Release 7.6.5 (February 2025)
+
+Couchbase Server 7.6.5 was released in January 2025.
+This maintenance release contains new features and fixes several known issues.
+
+For detailed information on new features and enhancements, see xref:introduction:whats-new.adoc[].
+
+[#fixed-issues-765]
+=== Fixed Issues
+
+This release contains the following fixes:
+
+==== Data Service
+
+[#table-fixed-issues-765-data-service,cols="10,40,40"]
+|===
+|Issue | Description | Resolution
+
+| https://jira.issues.couchbase.com/browse/MB-64742[MB-64742]
+| An issue in the plasma tracking stats flagged a stale recovery point in the recovery log as valid data.
+This made the log cleaning run slowly at a low mutation rate,
+and therefore, unable to trim the recovery point history effectively.
+At a higher mutation rate, the mutations alone could push the fragmentation ratio high enough to start the log cleaner,
+and therefore, was  able to trim the rp history despite the issue with tracking stats.
+
+
+| We  mark the latest version of the recovery point that exists in both the recovery log and the data log.
+This effectively means that plasma will keep the recovery point history list to 1 in the recovery log.
+In addition,
+the plasma tracking stats are fixed such that it no longer treats the older recovery point as valid data in the recovery log.
+This allows the log cleaner to run even at a low mutation rate.
+
+
+|===
+
+==== Query Service
+
+[#table-fixed-issues-765-query-service,cols="10,40,40"]
+|===
+|Issue | Description | Resolution
+
+| https://jira.issues.couchbase.com/browse/MB-64684[MB-64684]
+a| If an inline user-defined function (UDF) includes a query with a nested `ARRAY` construct,
+and the innermost `ARRAY` construct refers to both:
+
+* a UDF argument, and
+* the binding variable of an outer `ARRAY` construct,
+
+Then the UDF creation or execution could fail.
+
+| Issue resolved
+
+|===
+
+
+==== Search Service
+
+[#table-fixed-issues-765-search-service,cols="10,40,40"]
+|===
+|Issue | Description | Resolution
+| https://jira.issues.couchbase.com/browse/MB-64652[MB-64652]
+a| An issue  in versioning can cause an online upgrade-rebalance operation
+to fail on account of a planning algorithm betterment change. 
+The bug will also impact the failover-recovery online upgrade path.
+
+NOTE: This issue will only surface when an upgrade is attempted over a system with search indexes from `7.6.[0–3]` to `7.6.4`.
+
+| The issue has been resolved in version `7.6.5`. 
+Our recommendation is to avoid the issue by moving directly to this version.
+
+| https://jira.issues.couchbase.com/browse/MB-64764[MB-64764]
+| If an index was created during rebalance,
+and the rebalance is stopped before plans are computed for that index,
+then no plans or partitions are created for the index until a subsequent rebalance is completed.
+
+In `7.6.4` we introduced a change
+to compute the plans for indexes created during a rebalance even if the rebalance stops midway. 
+This inadvertently caused a regression where a subsequent rebalance can get stuck and fail continuously on timeouts.
+
+| In `7.6.5` we reverted the change: if the user aborts an ongoing rebalance, then plans for an index introduced during the operation may not be deployed until a subsequent rebalance operation is triggered and completed. 
+
+|===
+