Add v1.1 documentation with v1.0 versioning

Enable Docusaurus version dropdown (v1.1 current, v1.0 archived), v1.1 migration and New Architecture docs, v1.0 snapshot fixes, and doc content/link cleanup.

Author: jayant-dhingra-cb

README.md

@@ -47,7 +47,7 @@ If you are using GitHub pages for hosting, this command is a convenient way to b
 We truly appreciate your interest in this project!  
 This project is **community-maintained**, which means it's **not officially supported** by our support team.
 
-If you need help, have found a bug, or want to contribute improvements, the best place to do that is right here — by [opening a GitHub issue](https://github.com/Couchbase-Ecosystem/cbl-reactnative-docs/issues).  
+If you need help, have found a bug, or want to contribute improvements, the best place to do that is right here - by [opening a GitHub issue](https://github.com/Couchbase-Ecosystem/cbl-reactnative-docs/issues).  
 Our support portal is unable to assist with requests related to this project, so we kindly ask that all inquiries stay within GitHub.
 
-Your collaboration helps us all move forward together — thank you!
+Your collaboration helps us all move forward together - thank you!

docs/DataSync/remote-sync-gateway.md

@@ -5,7 +5,7 @@ sidebar_position: 2
 
 # Remote Sync 
 
-> Description - _Couchbase Lite for Ionic — Synchronizing data changes between local and remote databases using Sync Gateway or Capella App Services_
+> Description - _Couchbase Lite for Ionic - Synchronizing data changes between local and remote databases using Sync Gateway or Capella App Services_
 
 :::note
 All code examples are indicative only. They demonstrate the basic concepts and approaches to using a feature. Use them as inspiration and adapt these examples to best practice when developing applications for your platform.
@@ -56,7 +56,7 @@ Couchbase Mobile uses a replication protocol based on WebSockets for replication
 
 #### Incompatibilities
 
-Couchbase Lite’s replication protocol is incompatible with CouchDB-based databases. And since Couchbase Lite 2.x+ only supports the new protocol, you will need to run a version of Sync Gateway that supports it — see: [Compatibility](../ProductNotes/compatibility.md).
+Couchbase Lite’s replication protocol is incompatible with CouchDB-based databases. And since Couchbase Lite 2.x+ only supports the new protocol, you will need to run a version of Sync Gateway that supports it - see: [Compatibility](../ProductNotes/compatibility.md).
 
 ### Ordering
 
@@ -86,15 +86,15 @@ For backward compatibility with the code prior to >= 3.1, when you set up the re
 
 <div align="center">
 
-![Cbl Replication Scopes Collections 1](../../static/img/cbl-replication-scopes-collections-1.png)
+![Cbl Replication Scopes Collections 1](/img/cbl-replication-scopes-collections-1.png)
 
 </div>
 
 #### Sync Couchbase Lite default collection with default collection on Sync Gateway
 
 <div align="center">
 
-![Cbl Replication Scopes Collections 2](../../static/img/cbl-replication-scopes-collections-2.png)
+![Cbl Replication Scopes Collections 2](/img/cbl-replication-scopes-collections-2.png)
 
 </div>
 
@@ -106,15 +106,15 @@ The user-defined collections specified in the Couchbase Lite replicator setup mu
 
 <div align="center">
 
-![Cbl Replication Scopes Collections 3](../../static/img/cbl-replication-scopes-collections-3.png)
+![Cbl Replication Scopes Collections 3](/img/cbl-replication-scopes-collections-3.png)
 
 </div>
 
 #### Syncing scope with user-defined collections. Couchbase Lite has more collections than the Sync Gateway configuration (with collection filters)
 
 <div align="center">
 
-![Cbl Replication Scopes Collections 4](../../static/img/cbl-replication-scopes-collections-4.png)
+![Cbl Replication Scopes Collections 4](/img/cbl-replication-scopes-collections-4.png)
 
 </div>
 
@@ -259,7 +259,7 @@ config.addCollection(collectionName);
 ```
 
 :::note
-Note use of the scheme prefix (`wss://` to ensure TLS encryption — strongly recommended in production — or `ws://`)
+Note use of the scheme prefix (`wss://` to ensure TLS encryption - strongly recommended in production - or `ws://`)
 :::
 
 ### Sync Mode
@@ -298,7 +298,7 @@ In the event it detects a transient error, the replicator will attempt to reconn
 
 On each retry the interval between attempts is increased exponentially (exponential backoff) up to the maximum wait time limit (5 minutes).
 
-The REST API provides configurable control over this replication retry logic using a set of configiurable properties — see: [Table 1](#table-1-replication-retry-configuration-properties).
+The REST API provides configurable control over this replication retry logic using a set of configiurable properties - see: [Table 1](#table-1-replication-retry-configuration-properties).
 
 #### Table 1. Replication Retry Configuration Properties
 
@@ -308,7 +308,7 @@ The REST API provides configurable control over this replication retry logic usi
 | `maxAttempts()`        | Change this to limit or extend the number of retry attempts. | The maximum number of retry attempts. <br/> <br/> Set to zero (0) to use default values. <br/> <br/> Set to one (1) to prevent any retry attempt. <br/> <br/> The retry attempt count is reset when the replicator is able to connect and replicate. <br/> <br/> Default values are: <br/> - Single-shot replication = 9 <br/> - Continuous replication = maximum integer value. <br/> <br/> Negative values generate a Couchbase exception `InvalidArgumentException`. |
 | `maxAttemptWaitTime()` | Change this to adjust the interval between retries. | The maximum interval between retry attempts. <br/> <br/> While you can configure the maximum permitted wait time, the replicator’s exponential backoff algorithm calculates each individual interval which is not configurable. <br/> <br/> Default value: 300 seconds (5 minutes). <br/> <br/> Zero sets the maximum interval between retries to the default of 300 seconds. <br/> <br/> 300 sets the maximum interval between retries to the default of 300 seconds. <br/> <br/> A negative value generates a Couchbase exception, `InvalidArgumentException`.    |
 
-When necessary you can adjust any or all of those configurable values — see: [Example 5](#example-5-configuring-replication-retries) for how to do this.
+When necessary you can adjust any or all of those configurable values - see: [Example 5](#example-5-configuring-replication-retries) for how to do this.
 
 #### Example 5. Configuring Replication Retries
 
@@ -462,7 +462,7 @@ await replicator.start();
 
 Custom headers can be set on the configuration object. The replicator will then include those headers in every request.
 
-This feature is useful in passing additional credentials, perhaps when an authentication or authorization step is being done by a proxy server (between Couchbase Lite and Sync Gateway) — see [Example 10](#example-10-setting-custom-headers).
+This feature is useful in passing additional credentials, perhaps when an authentication or authorization step is being done by a proxy server (between Couchbase Lite and Sync Gateway) - see [Example 10](#example-10-setting-custom-headers).
 
 #### Example 10. Setting custom headers
 
@@ -506,6 +506,10 @@ await replicator.start();
 
 1. The callback should follow the semantics of a [pure function](https://en.wikipedia.org/wiki/Pure_function). Otherwise, long running functions would slow down the replicator considerably.
 
+:::note Version 1.1
+Android replication filters now support JavaScript arrow functions in the V8 evaluation path.
+:::
+
 ##### Pull Filter
 
 The pull filter gives an app the ability to validate documents being pulled, and skip ones that fail. This is an important security mechanism in a peer-to-peer topology with peers that are not fully trusted.
@@ -585,7 +589,7 @@ Users may lose access to channels in a number of ways:
     * User is removed from a role
     * A channel is removed from a role the user is assigned to
 
-By default, when a user loses access to a channel, the next Couchbase Lite Pull replication auto-purges all documents in the channel from local Couchbase Lite databases (on devices belonging to the user) unless they belong to any of the user’s other channels — see: [Table 2](#table-2-behavior-following-access-revocation).
+By default, when a user loses access to a channel, the next Couchbase Lite Pull replication auto-purges all documents in the channel from local Couchbase Lite databases (on devices belonging to the user) unless they belong to any of the user’s other channels - see: [Table 2](#table-2-behavior-following-access-revocation).
 
 Documents that exist in multiple channels belonging to the user (even if they are not actively replicating that channel) are not auto-purged unless the user loses access to all channels.
 
@@ -604,7 +608,7 @@ Users will be receive an `AccessRemoved` notification from the DocumentListener
 |                      | Sync Function includes `requireAccess(revokedChannel)`           | Local changes continue to be pushed to remote but are rejected by Sync Gateway |
 
 
-If a user subsequently regains access to a lost channel, then any previously auto-purged documents still assigned to any of their channels are automatically pulled down by the active Sync Gateway when they are next updated — see behavior summary in [Table 3](#table-3-behavior-if-access-is-regained).
+If a user subsequently regains access to a lost channel, then any previously auto-purged documents still assigned to any of their channels are automatically pulled down by the active Sync Gateway when they are next updated - see behavior summary in [Table 3](#table-3-behavior-if-access-is-regained).
 
 #### Table 3. Behavior if access is regained
 
@@ -639,7 +643,7 @@ This is an [Enterprise Edition](https://www.couchbase.com/products/editions/) fe
 
 With Delta Sync, only the changed parts of a Couchbase document are replicated. This can result in significant savings in bandwidth consumption as well as throughput improvements, especially when network bandwidth is typically constrained.
 
-Replications to a Server (for example, a Sync Gateway, or passive listener) automatically use delta sync if the property is enabled at database level by the server — see: [databases.$db.delta_sync.enabled](https://docs.couchbase.com/sync-gateway/current/configuration-properties-legacy.html#databases-foo_db-delta_sync).
+Replications to a Server (for example, a Sync Gateway, or passive listener) automatically use delta sync if the property is enabled at database level by the server - see: [databases.$db.delta_sync.enabled](https://docs.couchbase.com/sync-gateway/current/configuration-properties-legacy.html#databases-foo_db-delta_sync).
 
 Intra-Device replications automatically disable delta sync, whilst Peer-to-Peer replications automatically enable delta sync.
 
@@ -669,7 +673,7 @@ Replicators use `checkpoints` to keep track of documents sent to the target data
 
 Without `checkpoints`, Couchbase Lite would replicate the entire database content to the target database on each connection, even though previous replications may already have replicated some or all of that content.
 
-This functionality is generally not a concern to application developers. However, if you do want to force the replication to start again from zero, use the `checkpoint` reset argument when starting the replicator — as shown in Example 13.
+This functionality is generally not a concern to application developers. However, if you do want to force the replication to start again from zero, use the `checkpoint` reset argument when starting the replicator - as shown in Example 13.
 
 #### Example 13. Resetting checkpoints
 
@@ -691,7 +695,7 @@ The default `false` is shown here for completeness only; it is unlikely you woul
 
 You can monitor a replication’s status by using a combination of `Change Listeners` and the `Replicator.getStatus()` property. This enables you to know, for example, when the replication is actively transferring data and when it has stopped.
 
-You can also choose to monitor document changes — see: [Monitor Document Changes](#monitor-document-changes).
+You can also choose to monitor document changes - see: [Monitor Document Changes](#monitor-document-changes).
 
 ### Change Listeners
 
@@ -701,21 +705,21 @@ Use this to monitor changes and to inform on sync progress; this is an optional
 Don’t forget to save the token so you can remove the listener later
 :::
 
-Use the `Replicator` class to add a change listener as a callback to the Replicator (`addChangeListener()`) — see: [Example 14](#example-14-monitor-replication). You will then be asynchronously notified of state changes.
+Use the `Replicator` class to add a change listener as a callback to the Replicator (`addChangeListener()`) - see: [Example 14](#example-14-monitor-replication). You will then be asynchronously notified of state changes.
 
 You can remove a change listener with `removeChangeListener(token)`.
 
 ### Replicator Status
 
-You can use the `Replicator.getStatus()` property to check the replicator status. That is, whether it is actively transferring data or if it has stopped — see: [Example 14](#example-14-monitor-replication).
+You can use the `Replicator.getStatus()` property to check the replicator status. That is, whether it is actively transferring data or if it has stopped - see: [Example 14](#example-14-monitor-replication).
 
 The returned *ReplicationStatus* structure comprises:
 
-* `ActivityLevel` — stopped, offline, connecting, idle or busy — see states described in: [Table 5](#table-5-replicator-activity-levels)
+* `ActivityLevel` - stopped, offline, connecting, idle or busy - see states described in: [Table 5](#table-5-replicator-activity-levels)
 
 * `Progress`
-    * completed — the total number of changes completed
-    * total — the total number of changes to be processed
+    * completed - the total number of changes completed
+    * total - the total number of changes to be processed
 
 * `Error` - the current error, if any.
 
@@ -804,7 +808,7 @@ await token.remove();
 
 The following diagram describes the status changes when the application starts a replication, and when the application is being backgrounded or foregrounded by the OS. It applies to iOS only.
 
-![Replicator States](../../static/img/replicator-states.png)
+![Replicator States](/img/replicator-states.png)
 
 Additionally, on iOS, an app already in the background may be terminated. In this case, the `Database` and `Replicator` instances will be `null` when the app returns to the foreground. Therefore, as preventive measure, it is recommended to do a `null` check when the app enters the foreground, and to re-initialize the database and replicator if any of those is `null`.
 
@@ -964,7 +968,7 @@ By default, the WebSocket protocol uses compression to optimize for speed and ba
 
 ### Logs
 
-As always, when there is a problem with replication, logging is your friend. You can increase the log output for activity related to replication with Sync Gateway — see [Example 21](#example-21-set-logging-verbosity).
+As always, when there is a problem with replication, logging is your friend. You can increase the log output for activity related to replication with Sync Gateway - see [Example 21](#example-21-set-logging-verbosity).
 
 #### Example 21. Set logging verbosity
 
@@ -986,15 +990,15 @@ For more on troubleshooting with logs, see: [Using Logs](../Troubleshooting/usin
 
 ### Authentication Errors
 
-If Sync Gateway is configured with a self signed certificate but your app points to a `ws` scheme instead of `wss` you will encounter an error with status code 11006 — see: [Example 22](#example-22-protocol-mismatch)
+If Sync Gateway is configured with a self signed certificate but your app points to a `ws` scheme instead of `wss` you will encounter an error with status code 11006 - see: [Example 22](#example-22-protocol-mismatch)
 
 #### Example 22. Protocol Mismatch
 
 ```console
 CouchbaseLite Replicator ERROR: {Repl#2} Got LiteCore error: WebSocket error 1006 "connection closed abnormally"
 ```
 
-If Sync Gateway is configured with a self signed certificate, and your app points to a `wss` scheme but the replicator configuration isn’t using the certificate you will encounter an error with status code `5011` — see: [Example 23](#example-23-certificate-mismatch-or-not-found)
+If Sync Gateway is configured with a self signed certificate, and your app points to a `wss` scheme but the replicator configuration isn’t using the certificate you will encounter an error with status code `5011` - see: [Example 23](#example-23-certificate-mismatch-or-not-found)
 
 #### Example 23. Certificate Mismatch or Not Found
 

docs/Guides/Migration/v1.1.md

@@ -0,0 +1,77 @@
+---
+id: migration-guide-v1-1
+sidebar_position: 2
+---
+
+# Version 1.1
+
+> Description - _Quick reference for customer-facing changes in cbl-reactnative version 1.1_  
+> Related Content - [Release Notes](../../ProductNotes/release-notes.md) | [Using Logs](../../Troubleshooting/using-logs.md)
+
+## At a Glance
+
+Version 1.1 is focused on React Native New Architecture support and better troubleshooting:
+
+1. **TurboModules** - iOS and Android modules now support the React Native New Architecture.
+2. **Improved file logging** - React Native wrapper diagnostics can be written to file and custom log sinks.
+3. **LogSinks.write()** - application code can write messages into configured Couchbase Lite log sinks.
+4. **Reliability fixes** - listener cleanup, document expiration, and conflict-aware deletes are improved.
+
+## TurboModule Support
+
+Version 1.1 supports [React Native New Architecture](https://reactnative.dev/architecture/overview) through TurboModules. Existing application-level Couchbase Lite APIs remain largely compatible, but New Architecture should be enabled to use the TurboModule implementation.
+
+For Expo development builds, enable New Architecture in `app.json`:
+
+```json
+{
+  "expo": {
+    "newArchEnabled": true
+  }
+}
+```
+
+For React Native Android projects, make sure `newArchEnabled=true` is set in the Android project configuration.
+
+## Logging Changes
+
+### React Native Logs in File and Custom Sinks
+
+When a file or custom log sink is enabled, version 1.1 can forward React Native wrapper diagnostics into the same logging pipeline as native Couchbase Lite logs.
+
+React Native-originated lines are prefixed with `RN`:
+
+```text
+RN ::DEBUG:: database_Open
+RN ::WARNING:: query_RemoveChangeListener rejected: no listener for token
+RN ::ERROR:: collection_Save failed
+```
+
+This helps diagnose issues that cross the JavaScript/native boundary while keeping sensitive payloads out of forwarded logs.
+
+### Writing Application Logs
+
+Use `LogSinks.write()` to write application messages into configured Couchbase Lite sinks:
+
+```typescript
+import { LogSinks, LogLevel, LogDomain } from 'cbl-reactnative';
+
+await LogSinks.write(
+  LogLevel.WARNING,
+  LogDomain.DATABASE,
+  'Retrying database open after transient failure'
+);
+```
+
+## Smaller Behavior Improvements
+
+- Passing `null` to `setDocumentExpiration()` clears a document expiration.
+- Delete operations using `ConcurrencyControl.FAIL_ON_CONFLICT` reject stale revisions more consistently.
+- Query, collection, and replicator listener routing is more consistent on New Architecture builds.
+- Android replication filters support JavaScript arrow functions.
+- `FileSystem.getFilesInDirectory(path)` can list generated log files.
+
+## Repository Links
+
+- [couchbase/couchbase-lite-react-native](https://github.com/couchbase/couchbase-lite-react-native)
+- [couchbase/couchbase-lite-js-common](https://github.com/couchbase/couchbase-lite-js-common)

docs/Guides/Migration/v1.md

@@ -5,8 +5,8 @@ sidebar_position: 1
 
 # Version 1.0
 
-> Description — _Quick reference for all API changes in cbl-reactnative version 1.0_  
-> Related Content — [Release Notes](../../ProductNotes/release-notes.md) | [Using Logs](../../Troubleshooting/using-logs.md)
+> Description - _Quick reference for all API changes in cbl-reactnative version 1.0_  
+> Related Content - [Release Notes](../../ProductNotes/release-notes.md) | [Using Logs](../../Troubleshooting/using-logs.md)
 
 :::important AT A GLANCE
 Version 1.0 introduces several API changes: