fixed xarray instead of uppder-bound

README.md

@@ -29,7 +29,7 @@ A normal build-string for a python package (according to [conda-variants doc](ht
 
 Errors in the build-string can occur if they have an `-` (see [Build number and string](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#build-number-and-string)). **Attention**: For some reason, the build-string of the according `meta.yaml` gets ignored in some builds and therefore the package-hash is missing in the build-string. Not sure why this is happening. There were cases where the [Host](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#host) and/or the [Build](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#build) section of the `meta.yaml` were corrupted (e.g. too many unnecessary tools installed) and then the build-string was not build like specified in the according `meta.yaml`. This can have a huge impact if you don't know what you're doing if you trigger a new build. If you don't set the build-number properly, it can easily overwrite an existing live-build on [anaconda.org](https://anaconda.org/i4Ds). This is because if a package is overwritten or not solely relies on the uniqueness of the build-string, and without the hash it just consists of the package-version and the build-number. However, if you use a dev-build, you don't have to worry (make sure that the flag is set!!!), since they have an offset of the build-number of +1000).
 
-**Updating an already existing Wheel**: It may happen that an update of a dependency (direct or transversal) introduces a breaking change in a future release. Then, the current constraints of an existing conda-wheel is outdated an will most likely result in a broken environment. To prevent this, updating the according meta.yaml and increase the build-nr is not enough, because the solver doesn't just consider the largest build-numbers of conda-wheels. So, to fix this for current and also older releases, you have to relabel oudated conda-wheels to `legacy`. It was already mentioned in this paragraph, but don't forget to increase the build-number.
+**Updating an already existing Wheel**: It may happen that an update of a dependency (direct or transversal) introduces a breaking change in a future release. Then, the current constraints of an existing conda-wheel is outdated an will most likely result in a broken environment. To prevent this, updating the according meta.yaml and increase the build-nr is not enough, because the solver doesn't just consider the largest build-numbers of conda-wheels. So, to fix this for current and also older releases, you have to relabel oudated conda-wheels to `legacy`. Also do a comment in the meta.yaml, why you did constrain the dependency. This makes future builds where the constraints may have to be reconsidered way easier. It was already mentioned in this paragraph, but don't forget to increase the build-number.
 
 ## About MPI
 

ska-sdp-func-python/meta.yaml

@@ -34,7 +34,7 @@ requirements:
     - scipy                 >=1.10.1
     - ska-sdp-datamodels    ={{ SKA_SDP_DTMDL_VERSION_ALT }}
     - ska-sdp-func          ={{ SKA_SDP_FUNC_VERSION_ALT }}
-    - xarray                <=2023.2  # see issue #542 of Karabo
+    - xarray                =2023.2  # see issue #542 of Karabo
 
 about:
   home: https://gitlab.com/ska-telescope/sdp/ska-sdp-func-python/