rename from arsenic to cinnabar

[richardjgowers]

Description

Provide a brief description of the PR's purpose here.

Todos

Notable points that this PR has either accomplished or will accomplish.

• TODO 1

Questions

• Question1

Status

• Ready to go

[IAlibay]

codecov might take some time to get its act together unfortunately

[IAlibay]

All synched on the codecov end, lgtm!

[codecov]

Codecov Report

Merging #63 (f5fa7ba) into main (0870e93) will not change coverage.
The diff coverage is 100.00%.

[jchodera]

What's the plan regarding deprecation of the old conda package?

Would it make sense to release one more arsenic release to issue a warning on import that the package name has changed, and users should change their dependencies and imports to cinnibar to stay up to date with the latest releases? Or is the goal to completely change the API so it would not make sense to do so?

[IAlibay]

Ah yeah that's a great point @jchodera (sorry I think we got a bit trigger happy so we could get naming up for some upcoming talks).

I suspect we'll be looking at a pretty big API change (@mikemhenry can weigh in here), my 2 cent would be to make a clean break between packages. It would be nice to make a final 0.2.2 arsenic release based on current HEAD-1 in the git history though?

[richardjgowers]

I don't think we've made any changes since Mike did v0.2.1 a while ago.

[jchodera]

Further releases may not be required, but can you at least create a long-term maintenance branch from the 0.2.1 release version in case there's a critical bugfix that needs to be backported, or someone needs to look up the code for a deployed or historical release of arsenic?

[jchodera]

@mikemhenry : What's the best practice about renaming the historical releases to arsenic-x.y.z so it's clear which versions had the old package name?

[IAlibay]

can you at least create a long-term maintenance branch from the 0.2.1 release version in case there's a critical bugfix that needs to be backported

With previous experience in trying to do this in the past for MDA, taking on that maintenance burden (even for a branch with timed obsolescence as was the case for MDA) is a non-insignificant cost.

I understand why this is being asked, but who is meant to take charge of LTS for the historical arsenic code? It's not immediately clear to me that OpenFE has the bandwidth for things like keeping CI alive, making sure packaging still works etc...

[richardjgowers]

If we're interested in keeping arsenic around for posterity, we can (re)create a repo that has the last commit of v0.2.1, and cinnabar essentially becomes a fork of arsenic from that point.