ODB backwards compatibility limits

[maliberty]

Currently odb tries to be infinitely backwards compatible. It leads to complexity in the db loading code to maintain such. I propose a sliding window of one year backwards compatibility. As the tool is OSS, any old versions can be built as needed if a older db needs to be migrated in steps.

Currently this would imply removing all versions from before db_schema_update_db_power_switch

I'd like community input on this idea and duration. @gadfort @QuantamHD @rovinski @oharboe @donn or anyone else.

[oharboe]

I would be happy to trade backwards compatibility for eased maintenance burden. I cant think of relevant problems older than two months.

Could we make sure windows are overlapping and documented?

That way it is possible to convert old .odb by compiling oldest supporting version and load+save .odb from its supported version window to the next.

Though: I would forego this if it cant be automated. Perhaps keep oldest supported version in a separate file and document a git query that lists this information or a git blame with some grepping.

[donn]

For our part, we do not assume that Odb is backwards compatible at all. So yeah, we don't mind.

[oharboe]

The use case I can think of is limited to github issues reproduction archives.

We have not used or thought about using backwards comaptibility in production.

[donn]

For our part we always store our test cases as DEF/LEF, Guides, Segments, etc and generate the Odb ad-hoc

[QuantamHD]

I would say I'm strongly on the side of backwards compatibility. I think that we should try to push that window as long as possible. My kind of view of the situation is that we're trading a small amount of annoyance for us as devs, and multiplying it times the number of users who need to deal with it if we remove it. In general I feel OpenROAD should optimize for its ease of use and UX.

If we feel like the maintenance burden is too high we might consider moving to a more stable on disk format instead of just removing backwards compatibility.

That said I think 1-2 years (pushing much closer to two years) is probably long enough as long as there's sufficient documentation about how to get an odb to the latest version.