docs: Clean up discussion of very old versions.

docs/production/authentication-methods.md

@@ -616,10 +616,10 @@ other IdPs (identity providers). You can configure it as follows:
 The above configuration is sufficient for Service Provider initialized
 SSO, i.e. you can visit the Zulip web app and click "Sign in with
 {IdP}" and it'll correctly start the authentication flow. If you are
-not hosting multiple organizations, with Zulip 3.0+, the above
-configuration is also sufficient for Identity Provider initiated SSO,
-i.e. clicking a "Sign in to Zulip" button on the IdP's website can
-correctly authenticate the user to Zulip.
+not hosting multiple organizations, the above configuration is also
+sufficient for Identity Provider initiated SSO, i.e. clicking a "Sign
+in to Zulip" button on the IdP's website can correctly authenticate
+the user to Zulip.
 
 If you're hosting multiple organizations and thus using the
 `SOCIAL_AUTH_SUBDOMAIN` setting, you'll need to configure a custom
@@ -1040,9 +1040,9 @@ self-hosted servers. To do so, you'll need to do the following:
 
 ## OpenID Connect
 
-Starting with Zulip 5.0, Zulip can be integrated with any OpenID
-Connect (OIDC) authentication provider. You can configure it by
-enabling `zproject.backends.GenericOpenIdConnectBackend` in
+Zulip can be integrated with any OpenID Connect (OIDC) authentication
+provider. You can configure it by enabling
+`zproject.backends.GenericOpenIdConnectBackend` in
 `AUTHENTICATION_BACKENDS` and following the steps outlined in the
 comment documentation in `/etc/zulip/settings.py`.
 

docs/production/email.md

@@ -198,9 +198,9 @@ aren't receiving emails from Zulip:
   you can inspect the emails that reached the service, whether an
   email was flagged as spam, etc.
 
-- Starting with Zulip 1.7, Zulip logs an entry in
-  `/var/log/zulip/send_email.log` whenever it attempts to send an
-  email. The log entry includes whether the request succeeded or failed.
+- Zulip logs an entry in `/var/log/zulip/send_email.log` whenever it
+  attempts to send an email. The log entry includes whether the
+  request succeeded or failed.
 
 - If attempting to send an email throws an exception, a traceback
   should be in `/var/log/zulip/errors.log`, along with any other

docs/production/postgresql.md

@@ -1,7 +1,6 @@
 # PostgreSQL database details
 
-Starting with Zulip 3.0, Zulip supports a range of PostgreSQL
-versions:
+Zulip supports a range of PostgreSQL versions:
 
 ```{include} postgresql-support-table.md
 

docs/production/requirements.md

@@ -156,7 +156,11 @@ Zulip in production](install.md).
 
 This section details some basic guidelines for running a Zulip server
 for larger organizations (especially >1000 users or 500+ daily active
-users). Zulip's resource needs depend mainly on 3 parameters:
+users). These guidelines are conservative, since they are intended to
+be sufficient for a wide range of possible usage patterns that may not
+be applicable to your installation.
+
+Zulip's resource needs depend mainly on 3 parameters:
 
 - daily active users (e.g., number of employees if everyone's an
   employee)
@@ -177,7 +181,7 @@ installing Zulip with a dedicated database server.
   active users, we recommend using a [remote PostgreSQL
   database](postgresql.md), but it's not required.
 
-- **RAM:** We recommended more RAM for larger installations:
+- **RAM:** We recommend more RAM for larger installations:
 
   - With 25+ daily active users, 4 GB of RAM.
   - With 100+ daily active users, 8 GB of RAM.
@@ -225,23 +229,18 @@ installing Zulip with a dedicated database server.
   backend][s3-uploads].
 
 - **Sharding:** For servers with several thousand daily active users,
-  it is necessary to shard Zulip's Tornado service. Care must be taken
-  when dividing traffic for a single Zulip realm between multiple
-  Zulip application servers, which is why we recommend a hot spare
-  over load-balancing for most installations desiring extra
-  redundancy.
+  Zulip supports sharding its real-time-push Tornado service, both by
+  realm/organization (for hosting many organizations) and by user ID
+  (for hosting single very large organizations)
 
-  - Zulip 2.0 and later supports running multiple Tornado servers
-    sharded by realm/organization, which is how we scale Zulip Cloud.
-  - Zulip 6.0 and later supports running multiple Tornado servers
-    sharded by user ID, which is necessary for individual realms with
-    many thousands of daily active users.
+  Care must be taken when dividing traffic for a single Zulip realm
+  between multiple Zulip application servers, which is why we
+  recommend a hot spare over load-balancing for most installations
+  desiring extra redundancy.
 
-  [Contact us][contact-support] for help implementing the sharding policy.
-
-Scalability is an area of active development, so if you're unsure
-whether Zulip is a fit for your organization or need further advice
-[contact Zulip support][contact-support].
+If you have scalability questions or are unsure whether Zulip is a fit
+for your use case, contact [Zulip sales or support][contact-support]
+for assistance.
 
 For readers interested in technical details around what features
 impact Zulip's scalability, this [performance and scalability design