release: 0.1.1

[ChaoticTempest]

Cutting a patch version release on top of #46 so that it doesn't stall CI for some projects like near-sdk-rs. This won't have any API breaking changes, so should be fine making this a patch version release

[austinabell]

This comes with API breaking changes, so can't do as a patch release unless you release without #52.

Would releasing near/near-sandbox#21 as a patch release for sandbox be sufficient to fix this?

[ChaoticTempest]

@austinabell yeah, I'm going to be releasing it on top of the commit of #46 which doesn't have #52

Would releasing near/near-sandbox#21 as a patch release for sandbox be sufficient to fix this?

that's a good point, and yes it should. We can skip this release then since workspaces uses near-sandbox-utils = "0.1"

[austinabell]

@austinabell yeah, I'm going to be releasing it on top of the commit of #46 which doesn't have #52

Oops I misread you comment, that works!

that's a good point, and yes it should. We can skip this release then since workspaces uses near-sandbox-utils = "0.1"

Well, in this patch release we can bump the sandbox utils dep to 0.1.1 to ensure the previous isn't used?

[ChaoticTempest]

Well, in this patch release we can bump the sandbox utils dep to 0.1.1 to ensure the previous isn't used?

hmm, I see yeah. Cargo could cache 0.1.0 right? Specifically for projects that are already using 0.1.0? Then best to be explicit here then

[austinabell]

Well, in this patch release we can bump the sandbox utils dep to 0.1.1 to ensure the previous isn't used?

hmm, I see yeah. Cargo could cache 0.1.0 right? Specifically for projects that are already using 0.1.0? Then best to be explicit here then

If you use 0.1.1 that sets the minimum and would update that dependency if 0.1.0 is cached. That's the reason for setting this minimum. Doesn't really matter either way I don't think in this case.

[itegulov]

Nice, thanks!