Use same OpenROAD version number format for locally built and docker built OpenROAD

[oharboe]

Description

Docker OpenROAD uses OpenROAD 24Q3-8022-gb95651a925 whereas locally built uses OpenROAD v2.0-23930-g723f7c0bd0.

I much prefer OpenROAD v2.0-23930-g723f7c0bd0

Suggested Solution

Use OpenROAD v2.0-23930-g723f7c0bd0 format always.

Additional Context

No response

[vvbandeira]

We use the latest tag to create the local and Docker tags, and 24Q3 is the latest tag for OR.
What does your local git tag output? If you do git fetch --tags, does it still generate a v2.0.... tag when compiling again?

This might be a longer discussion, but I think we lack a consistent version naming scheme at the moment, especially considering that we use more of a "rolling release" rather than actual versions. Case in point, the number between 24Q3 (or v2.0) and the commit sha g123abc is the number of commits since the tag, 8000+ and almost 24000 commits between tag updates. @maliberty, any thoughts?

[maliberty]

@vvbandeira do you observe this issue in our builds? I would expect docker to make no difference in the latest tag it is based from.

[vvbandeira]

The correct tag is the 24Q3. The local tag that looks to be out of date.

I was wondering if you had any opinions on a tag scheme for us to use. Maybe bump the major version once every year and the minor every quarter so we keep v2.1, v2.2... rather than the 24q3

[oharboe]

I recommend doing what we have been doing, tag w format of v2.0.

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

Further, I propose bumping major and minor on a fixed schedule. There are enormously many good reasons to do a fixed schedule, not as a function of features or quality, and it is adopted widely in the industry.

Major every year, minor every quarter. PII marketing could post a blurv on each release. github supports presenting changes.

[rovinski]

I agree with @oharboe. I don't care as much about the semantics of a major vs. minor version, but a consistent versioning with regular releases would be very helpful. e.g. yosys and KLayout are both on a monthly release schedule for new versioned releases. People who want to keep on the head of the master branch are free to do so.

[maliberty]

We explicitly decided not to do official releases quite some time ago as we don't intend to fix bugs on older branches or do extra testing to make special releases. @mithro was strongly against it at the time arguing that it tends to divide the community across releases.

We can revisit but the tags should be consistent between docker and non-docker regardless which is all that is requested here.

[rovinski]

we don't intend to fix bugs on older branches

I don't think anyone's asking for that. There would still be a single branch of updates.

or do extra testing to make special releases.

Not necessary. Basically just automatically tagging the release once per month/quarter/whenever.

@mithro was strongly against it at the time arguing that it tends to divide the community across releases.

I mean, doesn't that already happen to an even larger degree? There is a constant stream of issues where the advice is "update to the head of master and try again" because people are using versions that are months old. The only difference would be in telling people to use the latest release, or perhaps use a nightly release. It would likely simplify downstream consumption of OR too, such as for LibreLane or any packagers.

One thing that would really help is just some kind of patch notes which outline the feature updates. GitHub has some automated features which I think help with this. But keeping up with the OR/ORFS PRs for update news is like trying to drink from a fire hose, and as far as I know there is no other public source.

Anyways, that's not really related to the issue at hand so I'll leave it there.

[maliberty]

If the 'release' is just a arbitrary periodic build tag then I don't get what its value is. I agree about a changelog.

[oharboe]

If the 'release' is just a arbitrary periodic build tag then I don't get what its value is. I agree about a changelog.

The value is that it aligns with the infrastructure available in github: create source release artifacts and no binaries and you get the release dropdown with a list of commits.

Though... OpenROAD chooses to retain review history faithfully, rather than clean commits, so the automatically generated release comments are going to be a mess, something curated will be needed in it's place. Don't know how that works with the github release GUI/user-experience.