- 2.0.15

diff --git a/doc/build/changelog/changelog_20.rst b/doc/build/changelog/changelog_20.rst
index b82297e3508ef1c33a09af5e3425d3e1828deb8c..c9adf3ec254337d2951489813029996b215167b1 100644 (file)
--- a/doc/build/changelog/changelog_20.rst
+++ b/doc/build/changelog/changelog_20.rst
@@ -10,7 +10,49 @@
 
 .. changelog::
     :version: 2.0.15
-    :include_notes_from: unreleased_20
+    :released: May 19, 2023
+
+    .. change::
+        :tags: bug, orm
+        :tickets: 9805
+
+        As more projects are using new-style "2.0" ORM querying, it's becoming
+        apparent that the conditional nature of "autoflush", being based on whether
+        or not the given statement refers to ORM entities, is becoming more of a
+        key behavior. Up until now, the "ORM" flag for a statement has been loosely
+        based around whether or not the statement returns rows that correspond to
+        ORM entities or columns; the original purpose of the "ORM" flag was to
+        enable ORM-entity fetching rules which apply post-processing to Core result
+        sets as well as ORM loader strategies to the statement.  For statements
+        that don't build on rows that contain ORM entities, the "ORM" flag was
+        considered to be mostly unnecessary.
+
+        It still may be the case that "autoflush" would be better taking effect for
+        *all* usage of :meth:`_orm.Session.execute` and related methods, even for
+        purely Core SQL constructs. However, this still could impact legacy cases
+        where this is not expected and may be more of a 2.1 thing. For now however,
+        the rules for the "ORM-flag" have been opened up so that a statement that
+        includes ORM entities or attributes anywhere within, including in the WHERE
+        / ORDER BY / GROUP BY clause alone, within scalar subqueries, etc. will
+        enable this flag.  This will cause "autoflush" to occur for such statements
+        and also be visible via the :attr:`_orm.ORMExecuteState.is_orm_statement`
+        event-level attribute.
+
+
+
+    .. change::
+        :tags: bug, postgresql, regression
+        :tickets: 9808
+
+        Repaired the base :class:`.Uuid` datatype for the PostgreSQL dialect to
+        make full use of the PG-specific ``UUID`` dialect-specific datatype when
+        "native_uuid" is selected, so that PG driver behaviors are included. This
+        issue became apparent due to the insertmanyvalues improvement made as part
+        of :ticket:`9618`, where in a similar manner as that of :ticket:`9739`, the
+        asyncpg driver is very sensitive to datatype casts being present or not,
+        and the PostgreSQL driver-specific native ``UUID`` datatype must be invoked
+        when this generic type is used so that these casts take place.
+
 
 .. changelog::
     :version: 2.0.14

diff --git a/doc/build/changelog/unreleased_20/9805.rst b/doc/build/changelog/unreleased_20/9805.rst
deleted file mode 100644 (file)
index a0b3ce9..0000000
--- a/doc/build/changelog/unreleased_20/9805.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-.. change::
-    :tags: bug, orm
-    :tickets: 9805
-
-    As more projects are using new-style "2.0" ORM querying, it's becoming
-    apparent that the conditional nature of "autoflush", being based on whether
-    or not the given statement refers to ORM entities, is becoming more of a
-    key behavior. Up until now, the "ORM" flag for a statement has been loosely
-    based around whether or not the statement returns rows that correspond to
-    ORM entities or columns; the original purpose of the "ORM" flag was to
-    enable ORM-entity fetching rules which apply post-processing to Core result
-    sets as well as ORM loader strategies to the statement.  For statements
-    that don't build on rows that contain ORM entities, the "ORM" flag was
-    considered to be mostly unnecessary.
-
-    It still may be the case that "autoflush" would be better taking effect for
-    *all* usage of :meth:`_orm.Session.execute` and related methods, even for
-    purely Core SQL constructs. However, this still could impact legacy cases
-    where this is not expected and may be more of a 2.1 thing. For now however,
-    the rules for the "ORM-flag" have been opened up so that a statement that
-    includes ORM entities or attributes anywhere within, including in the WHERE
-    / ORDER BY / GROUP BY clause alone, within scalar subqueries, etc. will
-    enable this flag.  This will cause "autoflush" to occur for such statements
-    and also be visible via the :attr:`_orm.ORMExecuteState.is_orm_statement`
-    event-level attribute.
-
-

diff --git a/doc/build/changelog/unreleased_20/9808.rst b/doc/build/changelog/unreleased_20/9808.rst
deleted file mode 100644 (file)
index 2294579..0000000
--- a/doc/build/changelog/unreleased_20/9808.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-.. change::
-    :tags: bug, postgresql, regression
-    :tickets: 9808
-
-    Repaired the base :class:`.Uuid` datatype for the PostgreSQL dialect to
-    make full use of the PG-specific ``UUID`` dialect-specific datatype when
-    "native_uuid" is selected, so that PG driver behaviors are included. This
-    issue became apparent due to the insertmanyvalues improvement made as part
-    of :ticket:`9618`, where in a similar manner as that of :ticket:`9739`, the
-    asyncpg driver is very sensitive to datatype casts being present or not,
-    and the PostgreSQL driver-specific native ``UUID`` datatype must be invoked
-    when this generic type is used so that these casts take place.
-

diff --git a/doc/build/conf.py b/doc/build/conf.py
index 23532bbbb60cf845df4e95e0f9ac09e2ac10c5d3..6a9c23451f644199a0c33f277cbe015d1c3aed5e 100644 (file)
--- a/doc/build/conf.py
+++ b/doc/build/conf.py
@@ -242,9 +242,9 @@ copyright = "2007-2023, the SQLAlchemy authors and contributors"  # noqa
 # The short X.Y version.
 version = "2.0"
 # The full version, including alpha/beta/rc tags.
-release = "2.0.14"
+release = "2.0.15"
 
-release_date = "May 18, 2023"
+release_date = "May 19, 2023"
 
 site_base = os.environ.get("RTD_SITE_BASE", "https://www.sqlalchemy.org")
 site_adapter_template = "docs_adapter.mako"