chore(dev/release): Ensure release verification passes for 0.2.0 (#375)

Author: paleolimbot

dev/release/README.md

@@ -22,13 +22,13 @@
 ## Verifying a release candidate
 
 Release candidates are verified using the script `verify-release-candidate.sh <version> <rc_num>`.
-For example, to verify SedonaDB 0.1.0 RC0, run:
+For example, to verify SedonaDB 0.2.0 RC0, run:
 
 ```shell
 # git clone https://github.com/apache/sedona-db.git && cd sedona-db
 # or
 # cd existing/sedona-db && git fetch upstream && git switch main && git pull upstream main
-dev/release/verify-release-candidate.sh 0.1.0 0
+dev/release/verify-release-candidate.sh 0.2.0 0
 ```
 
 Release verification requires a recent Rust toolchain. This toolchain can be installed
@@ -46,21 +46,23 @@ install the required dependencies:
 ```shell
 conda create -y --name verify-sedona-db
 conda activate verify-sedona-db
-conda install -y curl gnupg geos proj openssl libabseil cmake pkg-config
+conda install -y compilers curl gnupg geos proj openssl libabseil cmake make pkg-config
 export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$CONDA_PREFIX/lib"
 ```
 
-Currently, system libclang is required to generate C bindings at build time:
+When verifying via Docker or on a smaller machine it may be necessary to limit the
+number of parallel jobs to avoid running out of memory:
 
 ```shell
-apt-get update && apt-get install -y libclang-dev
+export CARGO_BUILD_JOBS=4
 ```
 
-When verifying via Docker or on a smaller machine it may be necessary to limit the
-number of parallel jobs to avoid running out of memory:
+Verifiers may opt in to additional features normally tested in CI with dedicated tooling.
+For example, to verify with specific Python build-time features, the `MATURIN_PEP517_ARGS`
+environment variable may be set.
 
 ```shell
-export CARGO_BUILD_JOBS=4
+export MATURIN_PEP517_ARGS="--features s2geography"
 ```
 
 ## Creating a release
@@ -71,8 +73,8 @@ a committer.
 
 ```shell
 git pull upstream main
-git branch -b branch-0.1.0
-git push upstream -u branch-0.1.0:branch-0.1.0
+git branch -b branch-0.2.0
+git push upstream -u branch-0.2.0:branch-0.2.0
 ```
 
 This push should cause two CI runs to begin:
@@ -98,8 +100,8 @@ When the state of the `branch-x.x.x` branch is clean and checks are complete,
 the release candidate tag can be created:
 
 ```shell
-git tag -a apache-sedona-db-0.1.0-rc0 -m "Tag Apache SedonaDB 0.1.0-rc0"
-git push upstream apache-sedona-db-0.1.0-rc0
+git tag -a apache-sedona-db-0.2.0-rc0 -m "Tag Apache SedonaDB 0.2.0-rc0"
+git push upstream apache-sedona-db-0.2.0-rc0
 ```
 
 This will trigger another packaging CI run that, if successful, will create a
@@ -114,7 +116,7 @@ The GPG_KEY_ID in dev/release/.env must have its public component listed in the
 
 ```shell
 # sign-assets.sh <version> <rc_number>
-dev/release/sign-assets.sh 0.1.0 0
+dev/release/sign-assets.sh 0.2.0 0
 ```
 
 After the assets are signed, they can be committed and uploaded to the
@@ -123,7 +125,7 @@ is provided:
 
 ```shell
 # upload-candidate.sh <version> <rc_number>
-APACHE_USERNAME=your_apache_username dev/release/upload-candidate.sh 0.1.0 0
+APACHE_USERNAME=your_apache_username dev/release/upload-candidate.sh 0.2.0 0
 ```
 
 ## Vote
@@ -140,17 +142,17 @@ Apache release repository. A helper script is provided:
 
 ```shell
 # upload-release.sh <version> <rc_number>
-APACHE_USERNAME=your_apache_username dev/release/upload-release.sh 0.1.0 0
+APACHE_USERNAME=your_apache_username dev/release/upload-release.sh 0.2.0 0
 ```
 
 An official GitHub tag must also be created:
 
 ```shell
-git tag -a apache-sedona-db-0.1.0 -m "SedonaDB 0.1.0" apache-sedona-db-0.1.0-rc0
-git push upstream apache-sedona-db-0.1.0
+git tag -a apache-sedona-db-0.2.0 -m "SedonaDB 0.2.0" apache-sedona-db-0.2.0-rc0
+git push upstream apache-sedona-db-0.2.0
 ```
 
-The prerelease located at <https://github.com/apache/sedona-db/releases/tag/apache-sedona-db-0.1.0-rc0>
+The prerelease located at <https://github.com/apache/sedona-db/releases/tag/apache-sedona-db-0.2.0-rc0>
 can now be edited to point to the official release tag and the GitHub release published
 from the UI.
 
@@ -189,19 +191,19 @@ are currently all derived from `Cargo.toml`, which can be updated to:
 
 ```
 [workspace.package]
-version = "0.2.0"
+version = "0.3.0"
 ```
 
 The R package must also be updated. R Packages use a different convention for development
-versions such that in preparation for 0.2.0 the development version should be
-`0.1.0.9000`. This is set the DESCRIPTION of the requisite package.
+versions such that in preparation for 0.3.0 the development version should be
+`0.2.0.9000`. This is set the DESCRIPTION of the requisite package.
 
 Development versions and the changelog are derived from the presence of a development
 tag on the main branch signifying where development of that version "started". After
 the version bump PR merges, that commit should be tagged with the appropriate
 development tag:
 
 ```shell
-git tag -a apache-sedona-db-0.2.0.dev -m "tag dev 0.2.0"
-git push upstream apache-sedona-db-0.2.0.dev
+git tag -a apache-sedona-db-0.3.0.dev -m "tag dev 0.3.0"
+git push upstream apache-sedona-db-0.3.0.dev
 ```

dev/release/verify-release-candidate.sh

@@ -262,8 +262,6 @@ test_python() {
   show_info "Installing Python package"
   rm -rf "${SEDONADB_TMPDIR}/python"
 
-  # Keep this export in sync with the export in .github/workflows/python.yml
-  export MATURIN_PEP517_ARGS="--features s2geography"
   pip install "sedonadb/[test]" -v
 
   show_info "Testing Python package"

python/sedonadb/python/sedonadb/__init__.py

@@ -19,6 +19,8 @@
 
 __version__ = _lib.sedona_python_version()
 
+__features__ = _lib.sedona_python_features()
+
 __all__ = ["connect", "options"]
 
 # Attempt to configure PROJ on import. This will warn if PROJ

python/sedonadb/src/lib.rs

@@ -53,6 +53,18 @@ fn sedona_python_version() -> PyResult<String> {
     Ok(VERSION.to_string())
 }
 
+#[cfg(feature = "s2geography")]
+#[pyfunction]
+fn sedona_python_features() -> PyResult<Vec<String>> {
+    Ok(vec!["s2geography".to_string()])
+}
+
+#[cfg(not(feature = "s2geography"))]
+#[pyfunction]
+fn sedona_python_features() -> PyResult<Vec<String>> {
+    Ok(vec![])
+}
+
 #[pyfunction]
 fn sedona_adbc_driver_init() -> PyResult<Py_uintptr_t> {
     let driver_init_void = AdbcSedonadbDriverInit as *const c_void;
@@ -91,6 +103,7 @@ fn _lib(py: Python<'_>, m: &Bound<'_, PyModule>) -> PyResult<()> {
     m.add_function(wrap_pyfunction!(configure_proj_shared, m)?)?;
     m.add_function(wrap_pyfunction!(sedona_adbc_driver_init, m)?)?;
     m.add_function(wrap_pyfunction!(sedona_python_version, m)?)?;
+    m.add_function(wrap_pyfunction!(sedona_python_features, m)?)?;
     m.add_function(wrap_pyfunction!(sedona_scalar_udf, m)?)?;
 
     m.add_class::<context::InternalContext>()?;

python/sedonadb/tests/functions/test_order.py

@@ -17,9 +17,14 @@
 
 import geopandas
 import geopandas.testing
+import pytest
+import sedonadb
 
 
 def test_order_sql(con):
+    if "s2geography" not in sedonadb.__features__:
+        pytest.skip("Ordering currently requires build with feature s2geography")
+
     wkt_unsorted = [
         None,
         "POINT EMPTY",