Toolkit brings a milestone version of sttp

[ghostdogpr]

The current toolkit uses a milestone version of sttp (v4.0.0-M1). Those milestone versions are not stable nor source compatible, so I think it might create instability for people using toolkit "latest".

Shouldn't the toolkit use stable releases? In that case v3.8.15.

I saw the comment in this PR saying that it was okay because the toolkit is still in experimental phase. Is it not going to be released any time soon? There's already documentation on the official website.

[SethTisue]

sttp 4 has big API changes that make it much more suitable for the toolkit than sttp 3 was. So including 3 really isn't an option here. I agree that depending on a milestone is only acceptable as a temporary measure.

(We are in a similar situation with MUnit: scalameta/munit#647)

[ghostdogpr]

I see your point. Maybe it's the usage of "latest" that should not be encouraged (it's great for getting started but your code might stop working anytime).

[bishabosha]

Maybe it's the usage of "latest" that should not be encouraged

I think even if the toolkit used stable versions toolkit "latest" would still imply that your always getting the latest version (plus any breakages) so maybe we should remind people of that in documentation, e.g. they want to deploy a toolkit-based script to prod, or just have a script that will last for years in their "useful stuff" folder

[armanbilge]

so maybe we should remind people of that in documentation, e.g. they want to deploy a toolkit-based script to prod, or just have a script that will last for years in their "useful stuff" folder

I also brought this issue up recently in the Scala CLI discord, and I finally opened an issue about it.

• A way to generate/rewrite directives to pin all the things for a stable, reproducible build VirtusLab/scala-cli#2145

[szymon-rd]

@ghostdogpr Toolkit did not get a stable release yet (we are on 0.x). We picked the sttp 4 purposedly, and the same goes for other milestone releases in the toolkit. We are putting together the versions of libraries that, once stabilized, will constitute the stable toolkit 1.0. If we were to choose older versions, we could not use the new APIs in tutorials; we would not gather feedback on how the libraries we want to proceed with work together at their current stage of development. The sttp 4 was particularly important, as the API redesign (lead by @adpi2) was partially motivated by the intent to put the sttp in the Toolkit.

In a few days, we will release the Toolkit 0.2, the public beta release. It still won't be a stable release. The purpose of this version would be to encourage people to use it, create threads for discussion and gather feedback. Once we have this feedback, we may introduce some breaking changes that will be allowed, as we are not developing a stable (1.x) version yet. However, given that we anticipate to have some users for 0.2, we guarantee best effort to not break their experience when bumping version of Toolkit.

After seeing that the DX of the toolkit is satisfactory and the community is satisfied with its shape, and that the libraries have their stable releases, we will release the Toolkit 1.0. Onwards from that, it's not best effort; it's hard guarantees and infrastructure for making sure.

[ghostdogpr]

@szymon-rd sounds good, thanks for the explanation 👍 I think what @armanbilge suggested would be great to ensure stability when writing durable things.