Replies: 6 comments 8 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
For our part, we do not assume that Odb is backwards compatible at all. So yeah, we don't mind. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
On the fence here. I don't consider odb to be a durable format - that is left to LEF/DEF/v. Although, I will say that for prior tapeouts using proprietary tools, we do keep chip designs around for a long time, and in order to open up the files I have to use the version of the tools that generated it in the first place, or at least around the same time period, because there is no guarantees on how long the db will last before being deprecated. Which is annoying. There is likely some kind of internal db versioning which isn't exposed to the user. It would be nice to have some kind of defined obsolescence mechanism in OR. Right now, things more or less 1) get removed right away or 2) get marked as deprecated and then sit around until someone notices and then removes it. It would be great to have a specific date when support will be removed and to have that semi or fully automatically removed. If support for old odb versions are removed, it would be nice to 1) have a strict maintenance period and have support removed promptly, 2) inform users if their odb version is old and when support will be removed, 3) if the support has already been removed, inform users of the last OR version that supports it. As @oharboe says, it would be extremely useful to have this upgrading phase automated if possible. And I agree with @QuantamHD that unless things start becoming overly complicated to maintain compatibility, why not just maintain support. It seems like most of the support is just wrapping the reading and writing in if statements, but I could be wrong on that. |
Beta Was this translation helpful? Give feedback.
-
|
I summarize this as no strong consensus in the community (don't care; 1.5 yrs; 2 months, etc). To @QuantamHD I've considered using sqlite as the on-disk format (not the runtime model for performance reasons). Schema migrations would be a bit more natural as we wouldn't be locked into the exact byte order. I think that transition itself would be painful to make backwards compatible. For schema migrations I like the idea in https://david.rothlis.net/declarative-schema-migration-for-sqlite/ (converted to c++ and possibly needing to handle data migrations occasionally). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions