Skip to content

next release? #254

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

Open
syntron opened this issue Apr 15, 2025 · 3 comments
Open

next release? #254

syntron opened this issue Apr 15, 2025 · 3 comments
Assignees

Comments

@syntron
Copy link
Contributor

syntron commented Apr 15, 2025

Is a new release of the OMPython package planned? The last release mentioned on github is v3.5.2 (2024/06/24) and 3.6.0 is available via pip (2024/07/12). However, the later version cannot be found on github; there is also no tag for this version.

@adeas31
Copy link
Member

adeas31 commented Apr 17, 2025

@arun3688 seems you forgot to tag 3.6.0 and only pushed it to pip.

@syntron yes a new release is planned since a lot of changes are done. Lets just wait until #249 and some other useful PRs are merged.

@syntron
Copy link
Contributor Author

syntron commented Apr 17, 2025

@adeas31: sounds good - no problem to wait

I have some additional changes in the pipeline - mainly some cleanup of the files:

  • move classes from init.py into separate files (=> OMCSession; ModelicaSystem)
  • move OMParser/init.py into just a directory

Reason:

  • separate the differnet classes / parser such that specific commits touch only the corresponding file
  • use init.py only for the package related definitions (public interface of the package)

I will check if I can prepare a PR for this

@ondras12345
Copy link
Contributor

ondras12345 commented Apr 17, 2025

I also have some changes ready that are waiting for #249 to be merged (otherwise there will be conflicts):

  • Fix two spaces in simflags causing error
  • Do not ignore subprocess returncode

I would also like to look into refactoring createCSVData and cleaning up the docstrings, but I'm not sure if I'll be able to do that in time for the release.

Edit: also, I would like to make linearize() return x0 and u0 (and all the other values, too). I'll have to think about how to do that without breaking backwards compatibility. I'll probably have to add a new function that returns a dataclass instead of a tuple.

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