Simon Hawkins

> > Just need open a PR to make a small change to Travis and then can close this. ([MacPython/pandas-wheels@b0845f7](https://github.com/MacPython/pandas-wheels/commit/b0845f7dfc1f49a6d9f304ab2d1c835aabe71d06)) > > [MacPython/pandas-wheels#191](https://github.com/MacPython/pandas-wheels/pull/191) travis green on main https://github.com/MacPython/pandas-wheels/runs/7915756330 so closing

> > does this need backport? > > Don't think so since `ZoneInfo` support will be new for 1.5. correct. the failures were only on nightlies (main). 1.4.x is passing...

Thanks @jorisvandenbossche. could be simpler to search and replace (the ??) after tagging in the release process. not really looked into this much yet.

> after tagging actually would need to be before tagging as automated commit. but that wouldn't be on master!

I have started to experiment with GitHub Actions for the Release Process. https://github.com/simonjayhawkins/pandas-release/actions?query=workflow%3A%22Manual+Release%22 In order to get workflows to trigger, appropriate permission are required. To experiment, have forked https://github.com/pandas-dev/pandas-release created...

Thanks @jreback. It may make sense to build the wheels **for release** in github actions from pandas as part of a single workflow, but we obviously don't want to duplicate...

Thanks @TomAugspurger dispatching events between repositories sort of leads to another big question. Should we keep pandas-release as a separate repo or include the release scripts in pandas?

also thinking out loud... if the release is more automated, would there be less of an issue with deleting the tag and restarting to process? We would obviously want a...

> (eg if we want to have an action triggered on a release _here_ in this repo, that action could also check out the separate repo) I could make changes...

> without having to deal with a "dirty" git state. the current process starts from HEAD. only the tag script needs to start from HEAD. once tagged the git state...