docs: usage approaches defined

Signed-off-by: Wilfred Almeida <[email protected]>

proposals/new/versatile-replication-filters.md

@@ -121,3 +121,123 @@ src/pkg/reg/util
 ├── util.go
 └── util_test.go
 ```
+
+
+---
+
+# Proposal Updates as per discussions
+
+Proposal updates as per discussion with [Vadim Bauer](https://twitter.com/vad1mo)
+
+Approach 2 specified in the proposal on taking regular expression from users is favored more.
+
+Various approaches to get this done that we discussed are as follows:
+
+
+
+1. **Add a new input field for regex:**
+
+    An additional input field to take user input can be added as follows along with the existing ones. Users can input an expression that will be matched against the artifacts' name, label, and tag.
+
+    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1682791477555/dcc6ea2d-be9f-4343-acc0-a633638e9a0b.png)
+
+
+**Pros:**
+
+* No migration is needed. Existing rules will continue working.
+
+* Users can switch to regex-based filtering at their convenience.
+
+
+**Cons:**
+
+* Logical and development complexity as novice users might need/try to combine regex and glob-based filtering which is complex to understand and develop.
+
+* The development effort needed is significant. UI portal, databases, API handlers, and filtering logic are some of the components that need to be modified which is time-consuming, complex, and has the potential of breaking and causing bugs.  
+
+
+
+2. **Accept regular expressions in existing input fields and distinguish between glob pattern and regex using some specifier like** `/<regex>/` **as follows**
+
+    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1682791786810/47f44272-f632-49a3-93ca-9a4b5df02d6a.png)
+
+
+**Pros:**
+
+* Reuse of existing UI
+
+* Existing filters continue working
+
+
+**Cons:**
+
+* Users might try to combine glob and regex rules which is complex to handle on the backend
+
+* Distinguishing between the glob rule and regex rule might fail at the backend due to unidentified edge cases
+
+* Database schema change needed to store glob rule and regex separately or a status field to indicate if a rule is a glob or regex  
+
+
+
+3. **Provide an option for choosing between glob and regex like following**
+
+    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1682792140270/b081d468-d45f-427f-a2f1-98254df55f77.png)
+
+
+**Pros:**
+
+* Easy to understand and use
+
+* Seamless, convenient migration
+
+
+**Cons:**
+
+* UI, API, and Database schema changes are needed to accept, process, and store regex rules which is a lot of work
+
+* Higher development and maintenance complexity  
+
+
+
+
+4. **Depreciate glob pattern and migrate completely to regex**
+
+    Pros:
+
+    * Instant migration to regex rules
+
+    * No need to maintain both regex and glob
+
+
+    Cons:
+
+    * Will break all existing installations and cause heavy migrations  
+
+
+
+
+5. **Accept both regex and glob on UI, implement regex filtering and convert glob rules to regex in the backend**
+
+    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1682792611965/2eba4664-3760-46e9-aacd-e91cf0d528bf.png)
+
+
+Existing glob rules stored in the database in can be converted to regex on runtime.
+
+New rules will be stored as regex
+
+A migration script can be provided to migrate existing glob rules to regex
+
+**Pros:**
+
+* Existing rules continue working
+
+* Regex filtering gets implemented without any change to the UI
+
+
+**Cons:**
+
+* Needs migration script
+
+* Might break if upgrade versions
+
+* Conversion of glob pattern to regex must have 100% coverage, any unidentified edge cases might break the working.