DOCSP-37592 v4.4 Ref Removal (#6787) (#6817)

* DOCSP-37592 v4.4 Ref Removal

* remove 'version 4.4'

* track 'mongodb 4.4'

* track 'v4.4'

* remove rest

* *

* build errors

* add ulimit note to include

* hedged read copy

* remove repetitive sentence

* *

* *

* namespace

* JD + IF feedback

* add minimum-lts-version

* final build errors

Author: ajhuh-mdb

snooty.toml

@@ -232,6 +232,7 @@ atlas-ui = "Atlas UI"
 mongosh = ":binary:`~bin.mongosh`"
 package-branch = "testing" # testing for dev rc releases
 windows-dir-version = "6.0" # wizard
+minimum-lts-version = "5.0"
 package-name-org = "mongodb-org"
 package-name-enterprise = "mongodb-enterprise"
 package-name = "mongodb"

source/administration/analyzing-mongodb-performance.txt

@@ -192,13 +192,12 @@ one or more of the following utilization statistics:
 
 .. note::
 
-   Starting in MongoDB 4.4, if the :binary:`~bin.mongod` process runs
-   in a :term:`container`, FTDC will report utilization statistics from
-   the perspective of the container instead of the host operating
-   system. For example, if a the :binary:`~bin.mongod` runs in a
-   container that is configured with RAM restrictions, FTDC will
-   calculate memory utilization against the container's RAM limit, as
-   opposed to the host operating system's total available RAM.
+   If the :binary:`~bin.mongod` process runs in a :term:`container`, FTDC 
+   reports utilization statistics from the perspective of the container 
+   instead of the host operating system. For example, if a the 
+   :binary:`~bin.mongod` runs in a container that is configured with RAM 
+   restrictions, FTDC calculates memory utilization against the container's 
+   RAM limit, as opposed to the host operating system's RAM limit.
 
 FTDC collects statistics produced by the following commands on
 file rotation or startup:

source/administration/production-notes.txt

@@ -865,8 +865,7 @@ consider the following recommendations:
 
   .. note:: 
 
-     Starting in MongoDB 4.4, a startup error is generated if the
-     ``ulimit`` value for number of open files is under ``64000``.
+     .. include:: /includes/fact-ulimit-minimum.rst
 
 - Disable Transparent Huge Pages. MongoDB performs better with
   normal (4096 bytes) virtual memory pages. See :doc:`Transparent Huge

source/core/aggregation-pipeline.txt

@@ -192,9 +192,8 @@ Some aggregation pipeline stages accept an :ref:`aggregation expression
 - Can contain additional nested :ref:`aggregation expressions
   <aggregation-expressions>`.
 
-Starting in MongoDB 4.4, you can use the :group:`$accumulator` and
-:expression:`$function` aggregation operators to define custom
-aggregation expressions in JavaScript.
+You can use the :group:`$accumulator` and :expression:`$function` aggregation 
+operators to define custom aggregation expressions in JavaScript.
 
 For all aggregation expressions, see :ref:`aggregation-expressions`.
 

source/core/csfle/reference/encryption-schemas.txt

@@ -168,7 +168,6 @@ Definition
   - ``bool``
   - ``object``
   - ``array``
-  - ``javascriptWithScope`` (*Deprecated*)
 
   If :autoencryptkeyword:`encrypt.algorithm` or its inherited value is
   ``AED_AES_256_CBC_HMAC_SHA_512-Random``, ``bsonType`` is

source/core/csfle/reference/supported-operations.txt

@@ -422,4 +422,3 @@ encrypted field to the following value types:
 - ``decimal128``
 - ``double``
 - ``object``
-- ``javascriptWithScope`` *(Deprecated)*

source/core/hashed-sharding.txt

@@ -9,7 +9,7 @@ Hashed Sharding
 
 Hashed sharding uses either a :ref:`single field hashed index
 <index-hashed-index>` or a :ref:`compound hashed index
-<index-type-compound-hashed>` (*New in 4.4*) as the shard key to
+<index-type-compound-hashed>` as the shard key to
 partition data across your sharded cluster.
 
 Sharding on a Single Field Hashed Index
@@ -28,7 +28,7 @@ Sharding on a Single Field Hashed Index
   value; this value is used as your shard key. [#hashvalue]_
 
 Sharding on a Compound Hashed Index
-  MongoDB 4.4 adds support for creating compound indexes with a single
+  MongoDB includes support for creating compound indexes with a single
   :ref:`hashed field <index-type-hashed>`. To create a compound hashed
   index, specify ``hashed`` as the value of any single index key when
   creating the index.
@@ -119,11 +119,8 @@ hashed index to use as the :term:`shard key`:
 
    - Starting in MongoDB 5.0, you can :ref:`reshard a collection
      <sharding-resharding>` by changing a collection's shard key.
-   - Starting in MongoDB 4.4, you can :ref:`refine a shard key
-     <shard-key-refine>` by adding a suffix field or fields to the
-     existing shard key.
-   - In MongoDB 4.2 and earlier, the choice of shard key cannot
-     be changed after sharding.
+   - You can :ref:`refine a shard key <shard-key-refine>` by adding a suffix 
+     field or fields to the existing shard key.
 
 Shard a Populated Collection
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

source/core/index-creation.txt

@@ -22,12 +22,11 @@ of the index build. The rest of the build process yields to interleaving
 read and write operations. For a detailed description of index build
 process and locking behavior, see :ref:`index-build-process`.
 
-Starting in MongoDB 4.4, index builds on a replica set or sharded
-cluster build simultaneously across all data-bearing replica set
-members. The primary requires a minimum number of data-bearing voting
-members (i.e. commit quorum), including itself, that must complete the
-build before marking the index as ready for use. A "voting" member is
-any replica set member where :rsconf:`members[n].votes` is greater than
+Index builds on a replica set or sharded cluster build simultaneously across 
+all data-bearing replica set members. The primary requires a minimum number of 
+data-bearing voting members (i.e. commit quorum), including itself, that must 
+complete the build before marking the index as ready for use. A "voting" member 
+is any replica set member where :rsconf:`members[n].votes` is greater than
 ``0``. See :ref:`index-operations-replicated-build` for more
 information.
 
@@ -267,10 +266,7 @@ when it is restarted and continues from the saved checkpoint. In earlier
 versions, if the index build was interrupted it had to be restarted
 from the beginning.
 
-Prior to MongoDB 4.4, the startup process stalls behind any recovered
-index builds. The secondary could fall out of sync with the replica set
-and require resynchronization. Starting in MongoDB 4.4, the
-:binary:`~bin.mongod` can perform the startup process while the
+The :binary:`~bin.mongod` can perform the startup process while the 
 recovering index builds.
 
 If you restart the :binary:`~bin.mongod` as a standalone (i.e. removing
@@ -297,18 +293,15 @@ there is still work to be done when the rollback concludes, the
 :binary:`~bin.mongod` automatically recovers the index build and
 continues from the saved checkpoint.
 
-Starting in version 4.4, MongoDB can pause an in-progress 
-index build to perform a :doc:`rollback </core/replica-set-rollbacks>`.
+MongoDB can pause an in-progress index build to perform a 
+:doc:`rollback </core/replica-set-rollbacks>`.
 
 - If the rollback does not revert the index build, MongoDB restarts 
   the index build after completing the rollback. 
 
 - If the rollback reverts the index build, you must re-create the 
   index or indexes after the rollback completes.
 
-Prior to MongoDB 4.4, rollbacks could start only after all in-progress 
-index builds finished.
-
 .. _index-creation-index-consistency:
 
 Index Consistency Checks for Sharded Collections
@@ -331,9 +324,8 @@ can occur, such as:
   fails to build the index for an associated shard or incorrectly
   builds an index with different specification.
 
-Starting in MongoDB 4.4 (and in MongoDB 4.2.6), the :doc:`config server
-</core/sharded-cluster-config-servers>` primary periodically checks for
-index inconsistencies across the shards for sharded collections. To
+The :ref:`config server <sharding-config-server>` primary periodically checks 
+for index inconsistencies across the shards for sharded collections. To
 configure these periodic checks, see
 :parameter:`enableShardedIndexConsistencyCheck` and
 :parameter:`shardedIndexConsistencyCheckIntervalMS`.
@@ -469,10 +461,9 @@ process:
     - A :binary:`~bin.mongod` that is *not* part of a replica set 
       skips this stage.
 
-      Starting in MongoDB 4.4, the :binary:`~bin.mongod` submits a
-      "vote" to the primary to commit the index. Specifically, it writes
-      the "vote" to an internal replicated collection on the
-      :term:`primary`.
+      The :binary:`~bin.mongod` submits a "vote" to the primary to commit the 
+      index. Specifically, it writes the "vote" to an internal replicated 
+      collection on the :term:`primary`.
 
       If the :binary:`~bin.mongod` is the :term:`primary`, it waits
       until it has a commit quorum of votes (all voting data-bearing

source/core/index-hidden.txt

@@ -13,8 +13,6 @@ Hidden Indexes
    :depth: 1
    :class: singlecol
 
-.. versionadded:: 4.4
-
 Hidden indexes are not visible to the :doc:`query planner
 </core/query-plans>` and cannot be used to support a query.
 
@@ -51,9 +49,7 @@ Restrictions
 ------------
 
 - To hide an index, you must have :ref:`featureCompatibilityVersion
-  <view-fcv>` set to ``4.4`` or greater. However, once hidden, the
-  index remains hidden even with :ref:`featureCompatibilityVersion
-  <view-fcv>` set to ``4.2`` on MongoDB 4.4 binaries.
+  <view-fcv>` set to ``{+minimum-lts-version+}`` or greater.
 
 - You cannot hide the ``_id`` index.
 
@@ -73,10 +69,8 @@ To create a ``hidden`` index, use the
 
    To use the ``hidden`` option with
    :method:`db.collection.createIndex()`, you must have
-   :ref:`featureCompatibilityVersion <view-fcv>` set to ``4.4`` or
-   greater. However, once hidden, the index remains hidden even with
-   :ref:`featureCompatibilityVersion <view-fcv>` set to ``4.2`` on
-   MongoDB 4.4 binaries.
+   :ref:`featureCompatibilityVersion <view-fcv>` set to 
+   ``{+minimum-lts-version+}`` or greater. 
 
 For example, the following operation creates a hidden ascending index
 on the ``borough`` field:
@@ -129,9 +123,7 @@ Hide an Existing Index
 .. note::
 
    - To hide an index, you must have :ref:`featureCompatibilityVersion
-     <view-fcv>` set to ``4.4`` or greater. However, once hidden, the
-     index remains hidden even with :ref:`featureCompatibilityVersion
-     <view-fcv>` set to ``4.2`` on MongoDB 4.4 binaries.
+     <view-fcv>` set to ``{+minimum-lts-version+}`` or greater. 
 
    - You cannot hide the ``_id`` index.
 

source/core/kerberos.txt

@@ -216,11 +216,10 @@ for details.
 Testing and Verification
 ------------------------
 
-Introduced alongside MongoDB 4.4, the :binary:`~bin.mongokerberos`
-program provides a convenient method to verify your platform's Kerberos
-configuration for use with MongoDB, and to test that Kerberos
-authentication from a MongoDB client works as expected. See the
-:binary:`~bin.mongokerberos` documentation for more information.
+The :binary:`~bin.mongokerberos` program provides a convenient method to 
+verify your platform's Kerberos configuration for use with MongoDB, and to 
+test that Kerberos authentication from a MongoDB client works as expected. 
+See the :binary:`~bin.mongokerberos` documentation for more information.
 
 :binary:`~bin.mongokerberos` is available in MongoDB Enterprise only.
 

source/core/map-reduce.txt

@@ -68,20 +68,6 @@ mapping. Map-reduce operations can also use a custom JavaScript
 function to make final modifications to the results at the end of the
 map and reduce operation, such as perform additional calculations.
 
-.. note::
-
-   Starting in MongoDB 4.4, :dbcommand:`mapReduce` no longer supports
-   the deprecated BSON type JavaScript code with scope
-   (:doc:`BSON type 15 </reference/bson-types/>`) for its functions. The
-   ``map``, ``reduce``, and ``finalize`` functions must be either BSON
-   type String (:doc:`BSON type 2 </reference/bson-types/>`) or
-   BSON type JavaScript (:doc:`BSON type 13 </reference/bson-types/>`).
-   To pass constant values which will be accessible in the ``map``,
-   ``reduce``, and ``finalize`` functions, use the ``scope`` parameter.
-
-   The use of JavaScript code with scope for the :dbcommand:`mapReduce`
-   functions has been deprecated since version 4.2.1.
-    
 Map-Reduce Results
 -------------------
 

source/core/query-plans.txt

@@ -152,7 +152,7 @@ Users can also:
 Plan Cache Debug Info Size Limit
 --------------------------------
 
-Starting in MongoDB 5.0 (and 4.4.3, 4.2.12, 4.0.23, and 3.6.23), the
+Starting in MongoDB 5.0, the
 :doc:`plan cache </core/query-plans>` will save full ``plan cache``
 entries only if the cumulative size of the ``plan caches`` for all
 collections is lower than 0.5 GB. When the cumulative size of the

source/core/queryable-encryption/reference/supported-operations.txt

@@ -433,4 +433,3 @@ following value types:
 - ``decimal128``
 - ``double``
 - ``object``
-- ``javascriptWithScope`` *(Deprecated)*

source/core/ranged-sharding.txt

@@ -54,12 +54,8 @@ to use as the :term:`shard key`.
 
    - Starting in MongoDB 5.0, you can :ref:`reshard a collection
      <sharding-resharding>` by changing a collection's shard key.
-   - Starting in MongoDB 4.4, you can :ref:`refine a shard key
-     <shard-key-refine>` by adding a suffix field or fields to the existing
-     shard key.
-   - In MongoDB 4.2 and earlier, the choice of shard key cannot
-     be changed after sharding.
-
+   - You can :ref:`refine a shard key <shard-key-refine>` by adding a suffix 
+     field or fields to the existing shard key.
 
 Shard a Populated Collection
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

source/core/read-preference-hedge-option.txt

@@ -6,18 +6,18 @@ Hedged Read Option
 
 .. default-domain:: mongodb
 
-Starting in MongoDB 4.4 for sharded clusters, you can specify the use
-of :ref:`hedged reads <mongos-hedged-reads>` for non-``primary``
-:doc:`read preferences </core/read-preference>`.
+You can specify the use of :ref:`hedged reads <mongos-hedged-reads>` for 
+non-``primary`` :doc:`read preferences </core/read-preference>` on sharded 
+clusters.
 
 With hedged reads, the :binary:`~bin.mongos` instances can route read
 operations to two replica set members per each queried shard and return
 results from the first respondent per shard.
 
 .. include:: /includes/list-hedged-reads-operations.rst
 
-To specify hedged read for a read preference, MongoDB 4.4 introduces
-the hedged read option for read preferences.
+To specify hedged read for a read preference, use the hedged read option for 
+read preferences.
 
 Enable Hedged Reads
 -------------------

source/core/read-preference-mechanics.txt

@@ -76,13 +76,12 @@ settings. The read preference is re-evaluated for each operation.
 Hedged Reads
 ````````````
 
-Starting in version 4.4, :binary:`~bin.mongos` supports :ref:`hedged
-reads <mongos-hedged-reads>` for non-``primary`` :doc:`read preferences
-</core/read-preference>` modes. That is, :binary:`~bin.mongos` can send
-an additional read to another member, if available, to hedge the read
-operation if using non-``primary`` :doc:`read preferences
-</core/read-preference>`. The additional read sent to hedge the read
-operation uses the ``maxTimeMS`` value of
+:binary:`~bin.mongos` supports :ref:`hedged reads <mongos-hedged-reads>` for 
+non-``primary`` :doc:`read preferences </core/read-preference>` modes. 
+That is, :binary:`~bin.mongos` can send an additional read to another member, 
+if available, to hedge the read operation if using non-``primary`` 
+:doc:`read preferences </core/read-preference>`. The additional read sent to 
+hedge the read operation uses the ``maxTimeMS`` value of
 :parameter:`maxTimeMSForHedgedReads`.
 
 .. include:: /includes/list-hedged-reads-operations.rst

source/core/read-preference.txt

@@ -23,7 +23,7 @@ Read preference consists of the :ref:`read preference mode
 <replica-set-read-preference-tag-sets>`, the :ref:`maxStalenessSeconds
 <replica-set-read-preference-max-staleness>` option, and the
 :ref:`hedged read <read-preference-hedged-read>` option. :ref:`Hedged read
-<read-preference-hedged-read>` option is available for MongoDB 4.4+ sharded
+<read-preference-hedged-read>` option is available for sharded
 clusters for reads that use non-``primary`` read preference.
 
 .. _read-pref-summary:
@@ -36,9 +36,8 @@ The following table lists a brief summary of the read preference modes:
 
 .. note::
 
-   Starting in version 4.4, non-``primary`` read preference modes
-   support :ref:`hedged read <mongos-hedged-reads>` on sharded
-   clusters.
+   Non-``primary`` read preference modes support 
+   :ref:`hedged read <mongos-hedged-reads>` on sharded clusters.
 
 .. include:: /includes/read-preference-modes-table.rst
 
@@ -114,7 +113,7 @@ Read Preference Modes
 
    .. note::
 
-      Starting in version 4.4, :readmode:`primaryPreferred` supports
+      Read preference :readmode:`primaryPreferred` supports
       :ref:`hedged reads <mongos-hedged-reads>` on sharded clusters.
 
 .. readmode:: secondary
@@ -139,7 +138,7 @@ Read Preference Modes
 
    .. note::
 
-      Starting in version 4.4, :readmode:`secondary` supports
+      Read preference :readmode:`secondary` supports
       :ref:`hedged reads <mongos-hedged-reads>` on sharded clusters.
 
 .. readmode:: secondaryPreferred
@@ -156,7 +155,7 @@ Read Preference Modes
 
    .. note::
 
-      Starting in version 4.4, :readmode:`secondaryPreferred` supports
+      Read preference :readmode:`secondaryPreferred` supports
       :ref:`hedged reads <mongos-hedged-reads>` on sharded clusters.
 
 .. readmode:: nearest
@@ -193,7 +192,7 @@ Read Preference Modes
 
    .. note::
 
-      Starting in version 4.4, read preference :readmode:`nearest`, by
+      Read preference :readmode:`nearest`, by
       default, specifies the use of :ref:`hedged reads
       <mongos-hedged-reads>` for reads on a sharded cluster.
 

source/core/replica-set-elections.txt

@@ -94,10 +94,9 @@ not seek election. For details, see
 Mirrored Reads
 ~~~~~~~~~~~~~~
 
-Starting in version 4.4, MongoDB provides :ref:`mirrored reads
-<mirrored-reads>` to pre-warm electable secondary members' cache with
-the most recently accessed data. With mirrored reads, the primary can
-mirror a subset of :ref:`operations
+MongoDB provides :ref:`mirrored reads <mirrored-reads>` to pre-warm 
+electable secondary members' cache with the most recently accessed data. 
+With mirrored reads, the primary can mirror a subset of :ref:`operations
 <mirrored-reads-supported-operations>` that it receives and send them
 to a subset of electable secondaries. Pre-warming the cache of a
 secondary can help restore performance more quickly after an election.