vinishjail97 opened a new pull request, #873: URL: https://github.com/apache/incubator-xtable/pull/873
## What The source `NOTICE` at the repository root still said `Copyright 2024-2025` while 0.4.0-incubating is being released in 2026. Bumps it to `2024-2026` and, more importantly, makes release validation catch this class of drift. Closes #872 ## Why Raised in the [0.4.0-incubating RC1 vote](https://lists.apache.org/thread/pjl0xgfns56bx219494oc51qnj2mll8b), where "Checked NOTICE file content and distribution years" came back `[KO]`. Only the hand-maintained root file was stale. The `NOTICE` inside the jars is generated by `maven-remote-resources-plugin` from the current year and already said `2024-2026`, so the source release and the convenience binaries disagreed with each other. This is the second occurrence: #692 fixed exactly the same thing for 2025. `release/scripts/validate_source_copyright.sh` asserted that `NOTICE` exists but never read it, so nothing stopped a stale copyright range from reaching a vote. ## Changes - `NOTICE`: copyright range `2024-2025` to `2024-2026`. - `release/scripts/validate_source_copyright.sh`: after the existing existence check, also verify that the copyright line is well formed, that it **starts** at the `pom.xml` `<inceptionYear>`, and that it **ends** at the year the release is being cut. This script is invoked from `validate_staged_release.sh`, so a stale `NOTICE` now fails release validation instead of surfacing during a vote. ## Testing Exercised the new check against several `NOTICE` variants: - `Copyright 2024-2026` (this PR) accepted - `Copyright 2024-2025` (what RC1 shipped) rejected, "must cover the release year 2026 but ends at 2025" - `Copyright 2024` rejected, same reason - `Copyright 2023-2026` rejected, "starts at 2023 but pom.xml `<inceptionYear>` is 2024" - `(c) 2024-2026 ASF` rejected, "does not contain a well-formed copyright line" Also ran it against the real `NOTICE` and `pom.xml` in the tree, which reports `[OK]` and exits 0. Note on portability: the year range is split with bash parameter expansion rather than a GNU `sed` branch, since release managers and verifiers run these scripts on both macOS and Linux. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
