fix: cargo clean before release build to avoid stale native libs

dev/release/build-release-comet.sh

@@ -125,6 +125,13 @@ docker build --no-cache \
 # Clean previous Java build
 pushd $COMET_HOME_DIR && ./mvnw clean && popd
 
+# Clean previous native build. This is required because common/pom.xml has
+# unconditional resource entries that bundle libcomet.dylib from
+# native/target/{x86_64,aarch64}-apple-darwin/release. If a release manager
+# previously cross-compiled those targets locally, stale dylibs would leak
+# into the release jars. See https://github.com/apache/datafusion-comet/issues/2232
+pushd $COMET_HOME_DIR/native && cargo clean && popd
+
 # Run the builder container for each architecture. The entrypoint script will build the binaries
 
 # AMD64

docs/source/contributor-guide/release_process.md

@@ -158,6 +158,21 @@ commit into the release branch.
 
 ### Build the jars
 
+#### A note on workspace cleanliness
+
+The `common/pom.xml` resource configuration unconditionally bundles
+`native/target/{x86_64,aarch64}-apple-darwin/release/libcomet.dylib` into the
+`common` jar when those files exist on disk. Maven's `clean` removes
+`common/target` but does not touch Cargo's `native/target` directory, so a
+stale dylib left over from a prior local `make release` or `make release-linux`
+on the release manager's workstation can silently end up in a release jar
+(see [#2232](https://github.com/apache/datafusion-comet/issues/2232) for the
+incident in 0.9.1).
+
+The `build-release-comet.sh` script now runs `cargo clean` for you, but as a
+defensive measure, prefer running the release build from a fresh clone of the
+repository rather than your day-to-day working tree.
+
 #### Setup to do the build
 
 The build process requires Docker. Download the latest Docker Desktop from https://www.docker.com/products/docker-desktop/.