Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Create mesa-models PyPI package #54

Open
tpike3 opened this issue Jul 20, 2023 · 8 comments
Open

Feature: Create mesa-models PyPI package #54

tpike3 opened this issue Jul 20, 2023 · 8 comments
Assignees

Comments

@tpike3
Copy link
Member

tpike3 commented Jul 20, 2023

Per Mesa #1707 we need to create mesa-model PyPI library for easy use access to models.

@tpike3 tpike3 self-assigned this Jul 20, 2023
@wang-boyu
Copy link
Member

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

@EwoutH
Copy link
Member

EwoutH commented Dec 10, 2023

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.

@Corvince
Copy link
Contributor

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.

@EwoutH
Copy link
Member

EwoutH commented Dec 10, 2023

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.

@EwoutH EwoutH self-assigned this Jan 21, 2024
@EwoutH
Copy link
Member

EwoutH commented Jan 21, 2024

I will try to get this working upcoming week.

@EwoutH
Copy link
Member

EwoutH commented Jul 3, 2024

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.

@wang-boyu
Copy link
Member

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?

@EwoutH
Copy link
Member

EwoutH commented Jul 4, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants