chore: bump litellm-enterprise 0.1.59 -> 0.1.60, litellm 1.99.0 -> 1.100.0

[yuneng-berri]

TLDR

Problem this solves:

• 1.99.0 line graduated (v1.99.0-rc.1 tagged); next promotion opens a new line
• enterprise/ changed since main but still publishes as 0.1.59
• Without bumps, the next release ships stale versions

How it solves it:

• Bumps root litellm 1.99.0 -> 1.100.0 (weekly MINOR, per release scheme)
• Bumps litellm-enterprise 0.1.59 -> 0.1.60 (PATCH) plus the root pin
• Refreshes uv.lock against the new versions

User Flow

Not applicable: this is a version metadata change only, no behavior changes. The next nightly and rc cut from staging will publish as 1.100.0.x instead of continuing the graduated 1.99.0 line

Relevant issues

None

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests (not applicable: version bump only, no behavior to test)
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Screenshots / Proof of Fix

There is no meaningful proof of fix for a version bump. The diff is the version lines in pyproject.toml and enterprise/pyproject.toml plus the matching uv.lock refresh; the lock's only other movement is the rolling exclude-newer timestamp, with no third-party package changes

Type

🚄 Infrastructure

Caveats (if any)

• litellm-proxy-extras (0.4.89) is unchanged since main, so no bump for it

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[greptile-apps]

Greptile Summary

The PR opens the next LiteLLM and enterprise release lines and keeps their package metadata synchronized.

• Bumps litellm from 1.99.0 to 1.100.0.
• Bumps litellm-enterprise from 0.1.59 to 0.1.60 and updates the root dependency pin.
• Refreshes matching editable-package versions and the resolution timestamp in uv.lock.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
enterprise/pyproject.toml	Keeps the enterprise project and Commitizen versions synchronized at 0.1.60.
pyproject.toml	Bumps the root project and Commitizen versions to 1.100.0 and aligns the enterprise dependency pin with 0.1.60.
uv.lock	Updates both editable workspace-package versions consistently and refreshes the dependency cutoff timestamp without changing third-party resolutions.

_{Reviews (2): Last reviewed commit: "bump: litellm-enterprise 0.1.59 -> 0.1.6..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_/release-version-bump-d43f8c (e5f7df0) with litellm_internal_staging (d16c4da)}

[yuneng-berri]

@greptileai