stub out package when StringView in Base

[stevengj]

Would be good to do this if JuliaLang/julia#60526 looks likely to be merged, cc @jakobnissen.

Probably the package should be updated at the same time to conform with the other semantic changes that were implemented in JuliaLang/julia#60526, and perhaps bumped to StringViews 2.0 for breaking changes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.57%. Comparing base (996d099) to head (f9e9673).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #36      +/-   ##
==========================================
+ Coverage   80.04%   80.57%   +0.53%     
==========================================
  Files           6        6              
  Lines         476      484       +8     
==========================================
+ Hits          381      390       +9     
+ Misses         95       94       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jakobnissen]

Looks good, but surely this stubbing is itself a breaking change.

Perhaps an alternative is to release a 2.0 to make StringViews semantics align with the Base version, and then release a version 2.99 which depends on Julia 1.14 (or whenever StringViews lands in Base), and simply reexports the Base versions, implementing nothing. This way, there is breakage from v1 to v2, but not from v2 to stubbing.

Would that work?

[stevengj]

Yes, that was my thought: 2.0 that implements Base semantics, then 2.1 (not sure why 2.99?) that stubs out if Base.StringViews is present.

Has there been any triage discussion yet of whether StringView is likely to be accepted into Base?

[jakobnissen]

The 2.99 is only so we can also release updates to the non-stub, e.g. 2.1, 2.2 etc. But maybe these should be patch releases only.

Yes, triage has accepted the PR as-is, but it needs a code review and then a merge from someone with merge permissions. So the details may still change, an in particular, I'd like someone to go through my proposed API changes w.r.t. this package with a fine-toothed comb to make sure the PR doesn't commit Base API to something dumb.

[stevengj]

It might be good to update this repo for the API changes first, and then see if downstream packages break.