[Release] Prepare repo for 0.2.2

[burtenshaw]

0.2.2 brings breaking changes defined in #342. Furthermore, we will decouple env specific releases from openenv-core release. i.e. envs in envs/ will have a pinned openenv-core dependency and not necessarily remain functional with main. To support this, we need to implement some changes.

Here's a rough plan of the core steps and PRs so far:

1. Fix the scripts so that agents can deploy all the envs in the repo independently. IMO, this is the best integration test for deployment, and a nice sanity check for new releases. Opened [1/2] Decouple Envs from version: Revive-scripts #392 and deployed 0.2.1 envs already using this branch.
2. As discussed, I would like to fix all the envs at the current version, and then pin them from now on. However, this require some smaller env specific fixes (f.e. conversion from 0.1.0 > 0.2.0). I have implemented these changes in this [2/2] Decouple Envs from version: Update /fix / pin all envs 0.2.0 #394
3. From then on, we will not need to maintain canonical envs on the hub and can instead just deploy when relevant. For example, an exciting env that uses a new feature of openenv.

Also, we should add some small fixes:

• lazy load core
• fix async handler to work with websockets

[Jiya126]

Hi @burtenshaw
I'd like to contribute, can work on 2. from update-envs-2.2.0 to fix all envs, readmes and their tests.

• Update all envs as per openenv-core>=0.2.1
• Invariants being followed in all envs (will use default async for all envs)
• Update readme
• Update env tests

After this, move on to update main documentation

I had some suggestions to add in environment design. Could you go through them once and we can select the ones required.

[qgallouedec]

not necessarily remain functional with main.

does it mean that in the future, upgrading openenv-core could break my env?

[qgallouedec]

from https://github.com/meta-pytorch/OpenEnv/pull/394/changes#diff-ef29ed8b4d3763181f81197d82db413c9c69e540b75bc9773c768c4fcfa617f4R11, it's a minimum openenv-core version, so I guess the answer is "it shouldn't".

[burtenshaw]

does it mean that in the future, upgrading openenv-core could break my env?

That is already the case. Your env is only compatible with the version of openenv-core that it was implemented for.

This issue just means that we stop maintaining the implementation of envs in this repo (envs/) to remain compatible with openenv-core on main.

If you're relying on an env. You should host it on the hub in your own namespace to validate reliability, and synchronise changes.