Would be great if there's also a readthedocs site for all the example models

We also should tag releases in sync with the main repo, so that the mesa examples are guaranteed to work with a certain mesa version.

For examples, if we tag 2.2.0 of Mesa, we should test and update all the Mesa examples for that version, and then also tag 2.2.0 for the Mesa examples.

Good idea, but I don't think we should be completely in sync. What happens when we add more examples or need a Bugfix for some example? If we then push the mesa-examples version, do we also push mesa to a higher version? This doesn't make sense, so we should probably only do it for Mayor.Minor versions and abuse the Bugfix version for updates to mesa examples. It won't be semver for Mesa examples, but semver doesn't make much sense for examples in the first place, so that should be fine

We could probably do this automatically when we release a new version of mesa via GitHub actions. But of course only if the models work on the new version.

We can just add an extra digit right? Like major.minor.patch.build.

Actually, I think PEP 440 post releases are perfect for this. Like 2.2.0.post1.

I will try to get this working upcoming week.

We also should tag releases in sync with the main repo, so that the mesa examples are guaranteed to work with a certain mesa version.

@projectmesa/maintainers I still think this is an idea worth perusing. Especially with the 3.0 changes incoming, it would be really nice to have an 2.3 branch with 2.3 tags, on which we can maintain examples, and a main branch on which we can develop new examples for 3.0.

Do we need separate branches for each tag, or is it possible to have only one main branch with all tags, similar to how packages are released?

I think for breaking changes we need to have branches. So probably mesa-2.x, mesa-3.x, etc