Johan Euphrosine

Looks that the failure is due to a recent schema version bump: https://github.com/The-OpenROAD-Project/OpenROAD/commit/6bea861cdb640856a643d8e7c42cb64feed3ab0a That happened since the last time `openroad_app` got bumped https://github.com/The-OpenROAD-Project/OpenLane/commit/ae089d8da840644f77d60eeeae7695c3f1948d7f

I was able to migrate the `.def` file from version `56` to version `57` using the following methodology: - install the most recent build of openroad preceding https://github.com/The-OpenROAD-Project/OpenROAD/pull/2267 (schema version...

@maliberty @donn @QuantamHD relaunched the CI the `arm64v8` which timeout'ed after 6h.

> CI failure Done.

@donn did you manage to work around the arm64 build timeout issue?

@maliberty conda-forge automation (as many other packaging system/distribution tend to do) relies on tagged release for referencing and updating upstream tarballs, see: https://conda-forge.org/docs/maintainer/adding_pkgs.html#maintainer-role https://conda-forge.org/docs/maintainer/updating_pkgs.html#how-does-regro-cf-autotick-bot-create-automatic-version-updates I agree that automated tagging is...

Yep, but as hinted my earlier comment conda-forge (and other packaging system/distribution) requires/strongly suggest that those tarballs comes from tagged release. A few of the reasons could be that: -...

> Tagging every commit is not a recipe for stability. Google explicitly shot down the idea of versioned releases previously when I proposed it. Sorry if I gave this impression,...

> I am hoping to make a bot to take monthly snapshots eventually to automate this depending on CI status. Maybe we could have this as a shared infrastructure that...

@trepetti I've started setting up something in my fork that run weekly https://github.com/proppy/OpenROAD/tags. https://github.com/proppy/OpenROAD/blob/sync/.github/workflows/github-actions-cron-release-from-head.yml Maybe we could run this in a shared project instead w/ some additional QA to vet...