Release v1.1.0

[iabaako]

Pull Request Summary 🚀

What does this PR do? 📝

Promotes the 1.1.0rc3 pre-release to the stable 1.1.0 release. Release documentation and the version bump only — no application code changes.

 pyproject.toml
-version = "1.1.0rc3"
+version = "1.1.0"

 CHANGELOG.md
 ## [Unreleased]          # now empty, ready for the next cycle
+## [1.1.0] - 2026-09-21  # all rc1–rc3 entries rolled in here

 RELEASENOTES.md
+## Version 1.1.0 — Reusable Project Setups   # new user-facing section
 ## Version 1.0.0 — Initial Release

Why is this change needed? 🤔

1.1.0rc3 has been through the pre-release cycle and is ready to ship to users as a final version. Per CONTRIBUTING.md, both CHANGELOG.md and RELEASENOTES.md must be updated before a release is tagged, and the version bump commit cannot be pushed to main directly because the branch is protected — hence this PR.

Merging it unblocks pushing the v1.1.0 tag, which triggers the release pipeline.

How was this implemented? 🛠️

Branched off the freshly merged main (d44692a), then:

1. RELEASENOTES.md — added a user-facing Version 1.1.0 — Reusable Project Setups section written in plain language per docs/release_notes_guide.md: project configuration export/import (feat: Export and import project configuration #251), Parquet import (feat: add support for Parquet file format in local file imports #245), survey ID in the correction log (feat: show Survey ID on the Correct Data page and in the Correction Log #264), the redesigned project picker, clearer prep confirmation messages (feat: standardize prep step confirmation messages #283), and the prep/correction fixes (fix: remove row(s) equal-to/not-equal-to conditions were inverted #263, bug: New imported data does not reflect on prep and correction pages #252, Standardize error handling for failed prep/correction steps during bulk reapply #253, fix: let the CLI auto-open the browser #284). Footer updated to September 2026 / 1.1.0.

   Internal-only work — the outliers subpackage split, ui_utils adoption, CI and dependency bumps, the justfile tag fix — is deliberately not in the release notes; it stays in CHANGELOG.md where developers look for it.

2. CHANGELOG.md — rolled the 17 [Unreleased] entries into ## [1.1.0] - 2026-09-21, leaving [Unreleased] empty for the next cycle.

3. Version bump — just bump-stable (1.1.0rc3 → 1.1.0), which updates pyproject.toml, re-syncs uv.lock, commits both, and creates the annotated v1.1.0 tag locally.

How to test or reproduce ? 🧪

git fetch origin && git checkout release/v1.1.0

uv run datasure --version    # -> DataSure 1.1.0
uv run python -m pytest      # -> exit 0, coverage gate (fail_under=80) satisfied
uv tool run pre-commit run --files CHANGELOG.md RELEASENOTES.md   # -> all hooks pass

Then read the new section at the top of RELEASENOTES.md and confirm the wording, the release name, and the September 2026 date are what we want in front of users — that text is not easily changed once published.

Review focus: the release notes wording and the version/date, not code behavior. Nothing runtime changes, so installed behavior is exactly 1.1.0rc3, already verified on Test PyPI.

Screenshots (if applicable) 📷

N/A — no UI changes.

⚠️ Post-merge step (one-way door)

The v1.1.0 tag exists locally only and was intentionally not pushed. After this merges:

git checkout main && git pull
git push origin v1.1.0

That tag push publishes to real PyPI (not Test PyPI — this is a final version), and a PyPI version number can never be reused. Confirm the rc3 Test PyPI build was smoke-tested before pushing. The release workflow's build job will fail if the tag does not match pyproject.toml; here both are 1.1.0.

Checklist ✅

• I have run and tested my changes locally
• I have limit this PR to less than 1000 lines of code change (if not, explain why)
• I have updated/added tests to cover my changes (if applicable) — n/a, docs and version only
• I have updated/added requirements to cover my changes (if applicable) — n/a, uv.lock re-synced by just bump-stable
• I have run linting and formatting on any code changes (if applicable)
• I have updated the documentation (README, etc.) accordingly — this PR is the documentation update
• I have reviewed and resolved any merge conflict — branched off current main, no conflicts

Reviewer Emoji Legend

	:code:	Meaning
😃👍💯	:smiley: :+1: :100:	I like this... ...and I want the author to know it! This is a way to highlight positive parts of a code review.
⭐⭐⭐	:star: :star: :star:	Important to fix before PR can be approved... And I am providing reasons why it needs to be addressed as well as suggested improvements.
⭐⭐	:star: :star:	Important to fix but non-blocking for PR approval... And I am providing suggestions where it could be improved either in this PR or later.
⭐	:star:	Give this some thought but non-blocking for PR approval... ...and consider this a suggestion, not a requirement.
❓	:question:	I have a question. This should be a fully formed question with sufficient information and context that requires a response.
📝	:memo:	This is an explanatory note, fun fact, or relevant commentary that does not require any action.
⛏	:pick:	This is a nitpick. This does not require any changes and is often better left unsaid. This may include stylistic, formatting, or organization suggestions and should likely be prevented/enforced by linting if they really matter
♻️	:recycle:	Suggestion for refactoring. Should include enough context to be actionable and not be considered a nitpick.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[NKeleher]

Ready to go!