Update UPGRADING.md

UPGRADING.md

@@ -64,6 +64,7 @@
     * The background loop will use `SyncronizationContext` to post events and callbacks to whatever thread/context started the main `SparkleUpdater` instance, which is why starting things on the main UI thread is recommended.
     * You can still do your own things with threads by handling events instead of passing a built-in `UIFactory` to `SparkleUpdater`, but this does not stop you from using a built-in `UIFactory` implementation to actually create said GUI elements. See the `NetSparkle.Samples.Forms.Multithread` sample.
     * For a sample of running WinForms on multiple UI threads while still using built-in UI objects, see the `NetSparkle.Samples.Forms.Multithread` sample.
+    * Note: passing your own `UIFactory` that starts windows/things on new threads into `SparkleUpdater` is not a supported configuration. It might work, it might not. Use at your own risk. 
   * NetSparkle basically makes no attempts to worry about threading now (e.g. calling to the main thread) except for the background loop calling to the main thread that started the `SparkleUpdater` instance. For most apps, this will be fine as they are just using their main UI thread.
   * Practically speaking, though, if you call `SparkleUpdater` functions on a background thread, subsequent events and things that are called as a result of that `SparkleUpdater` call will probably come back on the background thread that first called the event. Use at your own risk. When in doubt, for your own UI needs, make sure to check `InvokeRequired` on WinForms, and on WPF/Avalonia, marshal things to the UI thread (unless you're using data binding in which case it's handled for you!).