publish new tagged releases

[proppy]

As discussed in hdl/conda-eda#228 (comment), 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]

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]

@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	commit
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]

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]

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

[maliberty]

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

[proppy]

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]

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]

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 hdl/conda-eda#228 (comment)).

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 #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]

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]

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]

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]

@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]

@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]

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.