New release

[JaGeo]

@esoteric-ephemera I would like to make a new release. However, I believe that we made a lot of changes and wanted to aak if we have to think a bit further about backwards compatibility before the release.

[esoteric-ephemera]

Hey sorry I've been on vacation - I would say:

1. Ensure open issues which are easily resolved get fixed
2. Merge in PRs that are non-controversial (dependency upgrades) or mentioned in the paper
3. Put out the 0.1.0 beta release of atomate2

[JaGeo]

Sounds good.

2. I would focus on those that do not need a large discussion as well.

We should potentially move the ff workflow adaptations to after the release. Instead, we might just Update the documentation for now

I think it is most important that we have a version fast that does not fail running when installed with pip install atomate2.

[computron]

Any idea when the new release will happen? I was hoping to use the changes

We should potentially move the ff workflow adaptations to after the release. Instead, we might just Update the documentation for now
I think it is most important that we have a version fast that does not fail running when installed with pip install atomate2.

Will the ff workflow adaptations cause failed runs? To me it seems the opposite, the current workflow causes failures.

[esoteric-ephemera]

0.1.0 is out

[JaGeo]

Thanks @esoteric-ephemera !

I am wondering one thing: should we go back to a strict version with strict version numbers? Not => but ==. This would certainly safe us some urgency is something like this happens

[computron]

@JaGeo are you referring to pinning the dependencies? If so, this may be a good read:
https://chrisgorgo.medium.com/to-pin-or-not-to-pin-dependencies-reproducible-vs-reusable-software-ae92e16f0150

tldr - for reusable libraries meant to be used with other software, usually nicer to not pin the dependency

[JaGeo]

I am referring to the strict installation setting only, installed with pip install atomate2[strict]

[esoteric-ephemera]

We can pin below upper versions if we know a release is incoming (e.g., pandas 3 or numpy 3) but I would avoid strict deps unless necessary

[utf]

Just fyi, the strict dependencies are only to ensure that CI runs are reproducible.

The reason we originally added strict is because updates in pymatgen/emmet etc were continually breaking atomate2 and it was difficult to check whether failing PRs were due to their content or something else. My suggestion would be reinstate strict dependencies for this reason. We already do checking against minimal and maximal supported versions anyway, and the default Pypi versions are unpinned.

[esoteric-ephemera]

Probably a good idea to add in a strict dependency back for CI testing, have done that here