Why the split between v1 and v2?

[tom-sherman]

What purpose does this serve?

If the library is in a period of breaking changes, why not lump them all into v1?

Do you intend to support v1 and v2 simultaneously?

[TheSpyder]

When we forked this library we decided to take the opportunity to update a bunch of the APIs while there was less pressure on maintaining compatibility. However before we could do any of that I discovered ReScript 10 breaks bs-webapi. Certainly on the currently published ReScript 10 builds it is unusable.

Thus v1 was created, and our major breaking changes moved to v2. The purpose now is for v1 to be a safe haven for users of bs-webapi and bs-fetch. Those libraries still work perfectly on ReScript 9 today but I am expecting a lot of people will suddenly need to start using this once ReScript 10 lands. It's impossible to have zero breaking changes in v1, but I want it to be easy to migrate to.

I am not planning to support both v1 and v2. I am expecting that v2 will live on a branch (possibly with pre-releases published under a @next tag) for at least a few months, certainly until our early adopters are happy with the API.

[tom-sherman]

Ah, I see thanks! So v1 is a migration target, if those users need new features/fixes they'll need to upgrade to V2 - makes sense.