publish new tagged releases

proppy commented 1 year ago

As discussed in https://github.com/hdl/conda-eda/pull/228#issuecomment-1201078808, we'd need to get releases tagged in order to publish an OpenROAD to https://conda-forge.org/.

Latest tag https://github.com/The-OpenROAD-Project/OpenROAD/tree/v2.0 is ~1yo, would it be possible to get another release tagged.

Alternatively the project could use a strategy similar to https://github.com/chipsalliance/verible/blob/master/.github/workflows/verible-ci.yml#L340 to get version tagged on every commit.

Let me know what you think.

maliberty commented 1 year ago

Why can't you use a commit id? Tagging every commit is horrible and makes tags nearly useless. Not to mention tags can be moved so it is less stable than a commit id.

proppy commented 1 year ago

@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 not ideal for a mature project, as, if not careful implemented, it can loose some of the semantic around the versioning of the repo. I believe verible use it because they are still < 1.0 and are basically implementing https://semver.org/#spec-item-4:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Based on the release history, I can spot a few patterns currently being used for versioning OpenROAD: https://github.com/The-OpenROAD-Project/OpenROAD/tags	tag	date
v2.0	Jul 17, 2021	a5a5658
2021_03_09_stable	Mar 10, 2021	0f5a83c
v1.0rc2	Oct 17, 2020	c30c26e
v0.9.0-beta	Jul 7, 2020	2f8a74e

1-2 releases per year
Only major release v0 -> v1 -> v2, or dated version for specific occasion

Assuming this is consistent I have a few questions:

Will the next tagged version of OpenROAD will be v3.0? If yes, do you have an idea yet of what the feature sets/issues to be fixed are to reach it? (maybe creating a GitHub milestone would be handy).
Can we get a (minor?) tag including a subset of the changes between v2.0 and master (4632 commits) so that we can make progress on the packaging effort?

maliberty commented 1 year ago

The only pattern is that we are obliged by contract to have certain releases. We don't really have formal releases in general and follow @mithro advice to keep everyone at head.

We can add a specific tag for testing but setting up a tag based methodology isn't a good long term strategy. We don't intend to support those tags if there are problems by anything other than telling someone to move to head.

maliberty commented 1 year ago

You can build from a tarball so can you use something like https://github.com/The-OpenROAD-Project/OpenROAD/tarball/4a99e88667b0840531ca0096c4fa0da8f80d6cb1 ?

maliberty commented 1 year ago

https://conda-forge.org/docs/maintainer/adding_pkgs.html#tarballs-no-repos

proppy commented 1 year ago

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:

intermediate commit are often considered unstable
releases w/ changelog are the standard way to convey distribution readiness in the wider software community
automation for bumping version in recipe and generating new package versions are based on those releases metadata

Keeping everyone at HEAD sounds like a valid strategy if everyone is building from source, but having some form of release/versioning is desirable if we want to ease redistribution of OpenROAD in various packaging system.

maliberty commented 1 year ago

Tagging every commit is not a recipe for stability. Google explicitly shot down the idea of versioned releases previously when I proposed it. Please coordinate with @mithro on a unified stance. I believe we've had this same conversation before...

proppy commented 1 year ago

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, but I didn't meant to push for one versioning strategy over the other. Each projects have differents cycles of stability, and it's ultimatly the decision of the project maintainers find a release cycle and versioning strategy that better fit the expectation they want to set for their user base.

I'm mainly interested to find out if there is a desire from the project maintainers to find "one versioning strategy" that can make the packaging story for OpenROAD across different packaging system/distribution easier (as we were discussing w/ potential contributors in https://github.com/hdl/conda-eda/pull/228#issuecomment-1214471947).

Google explicitly shot down the idea of versioned releases previously when I proposed it. Please coordinate with @mithro on a unified stance. I believe we've had this same conversation before...

@mithro should be free to jump in here too, I'm just one extra data point and I'm not convinced an unified stance is a strict prior requirements to have this conversation in the open.

I could only find this one issue https://github.com/The-OpenROAD-Project/OpenROAD/issues/205 discussing a similar need in the project history, maybe other packagers could also comment on how versioning strategies impacts their effort to package and redistribute OpenROAD?

@sequencer for Arch
@cbalint13 for Fedora
@trepetti for NixOS
@rubund for Debian/Ubuntu (OpenSTA)

trepetti commented 1 year ago

For nixpkgs, I originally packaged it at 2.0 and assumed there would be semver releases, but just recently, it became clear that this style of release had been dropped, so the package now uses the unstable-yyyy-mm-dd format. I am hoping to make a bot to take monthly snapshots eventually to automate this depending on CI status. If there is a bug that is fixed in at HEAD but not in the package cache, versioning can be overridden programmatically by Nix users if they have the commit ID and the SHA256 hash for the tarball. This way, the project can be tracked pretty closely, and there will always be a reasonably recent binary in the cache in the absence of formal releases.

QuantamHD commented 1 year ago

Not part of the official team: The two tagged releases were done to satisfy a contract requirement, and did not signal a decision around versioning.

proppy commented 1 year ago

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 all downstream packagers could leverage?

trepetti commented 1 year ago

@proppy Most likely it will be Nix-specific but open, yes. For the next several releases, I will do it manual for the next several version bumps, most likely.

proppy commented 1 year ago

@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 the upstream tarball before tagging?

proppy commented 1 year ago

I'd also love it hear from @maliberty (w/ input from @QuantamHD and @mithro) if they think that something like https://en.wikipedia.org/wiki/Rolling_release could be an appropriate releasing strategy for the project, and if yes at which frequency (weekly? monthly? daily?).

https://cloud.google.com/blog/topics/developers-practitioners/how-google-got-to-rolling-linux-releases-for-desktops has some pointer on how this was implemented for Google gLinux distribution (based on debian testing).

This frequency of updates required us to redesign a lot of systems and processes. While originally intending more frequent releases, we found that for us, weekly releases were a sweet spot between moving quickly and allowing for proper release qualification, limiting the disruption to developer productivity.

maliberty commented 1 year ago

I'm not clear from the links as to what exactly is requested. Is a rolling release just whenever the tests pass or something more? Is there any expectation of a fix to a rolling release that is not just at the current head? To the degree that this is all automatic and of minimal impact I am agnostic.

proppy commented 1 year ago

Is a rolling release just whenever the tests pass or something more?

Yes pretty much, you'd need to decide on two things:

the cadence of the release (daily, weekly, bi-weekly, monthly?)
the tests required to validate the release (what's in test/*, https://github.com/The-OpenROAD-Project/OpenLane-MPW-CI, more?)

Is there any expectation of a fix to a rolling release that is not just at the current head?

You could explicit set the expection that bugs fixed at HEAD are (by virtue of the process) to be included in "next rolling release".

maliberty commented 1 year ago

Also OpenROAD-flow-scripts-Nightly-Public and OpenROAD-public.

Is this fully automatable? If so I don't care what the frequency is. If not I would pick the longest period possible.

proppy commented 1 year ago

Is this fully automatable?

Yep, I started something at in my fork at https://github.com/proppy/OpenROAD/blob/sync/.github/workflows/github-actions-cron-release-from-head.yml and sync the tree from upstream at a given frequency and cut a new tag if it doesn't already exist for that commit.

I was thinking of proceeding this way:

[ ] add steps to query the Jenkins status for the current commit being considered for tagging
[ ] let it run for a few days to create a few release in my fork
[ ] send a PR against the https://github.com/The-OpenROAD-Project/OpenROAD to integrate it w/ the rest of .github/workflows

If so I don't care what the frequency is. If not I would pick the longest period possible.

@trepetti what would be the ideal frequency for nixpkgs? I'm tempted to think weekly could be a good first pick; we can always adjust the frequency depending of each distribution needs as the tag get actually used.

vijayank88 commented 11 months ago

https://github.com/Precision-Innovations/OpenROAD/releases has maintaining the tags by latest.

proppy commented 9 months ago

@vijayank88 thanks for pointing this out! Do you plan to also populate the tag on this repo?

vijayank88 commented 9 months ago

@proppy I don't have information on your question. Maybe @maliberty have?

maliberty commented 9 months ago

Those 'releases' are just nightly builds. GH just provide releases as the mechanism for distribution. We don't make any guarantee of stability.

There is no plan to tag them for all the reasons discussed above.

joamatab commented 5 months ago

I can send a PR for an automatic release drafter, similar to the one we use in gdsfactory

proppy commented 5 months ago

filed https://github.com/berkeley-abc/abc/issues/267 and https://github.com/The-OpenROAD-Project/OpenSTA/issues/208

proppy commented 5 months ago

@vijayank88 it would be nice for the tarball at https://github.com/Precision-Innovations/OpenROAD/releases to include the source for abc and OpenSTA in order to make the build more readily reproducible.

maliberty commented 5 months ago

@vijayank88 doesn't produce those builds - @vvbandeira would be the right person to help. That said those are submodules so you can easily do an init to get the code.

proppy commented 5 months ago

you can easily do an init to get the code.

sadly GitHub release tarballs don't include git metadata nor information, see: https://github.com/dear-github/dear-github/issues/214

maliberty commented 5 months ago

Is there any GH mechanism to do what you want?

mithro commented 5 months ago

You can get GitHub release tarballs to include git information this way -> https://github.com/YosysHQ/yosys/pull/3138/files

The-OpenROAD-Project / OpenROAD

publish new tagged releases #2153