Backward compatibility guarantees

[parched]

What backward compatibility guarantees does BHoM make for serialized data? We are considering using BHoM for our data model, but we want to be able to save our data model to file now, and then still be able to open it with BHoM v100 in 10+ years time.

From my understanding, the upgrader will handle that sort of thing generally quite nicely, but is it guaranteed that it will? This section in the wiki seems to indicate it won't be guaranteed. Will it be different when BHoM is out of beta? If so, is there a timeline for that?

We would really like to use BHoM to save us defining our own model and to contribute to the community instead, but this is a blocker for us.

[adecler]

Hi @parched ,

Our policy around backward compatibility is fairly strict: No PR can be merged to the main unless the changes it contains are covered by versioning. This is enforced by our BHoMBot that will test on each PR if all types of object and methods from the previous beta can still be deserialised successfully after merging the PR. We are also testing every new beta version prior its release to make sure it can successfully deserialise all content from the last three beta versions. The versioning toolkit is capable of chaining version upgrades so this should cover your 10+ years requirement.

As you highlighted from our wiki, there will always be rare cases where an object or method is simply removed from the BHoM without replacement. It is important to make the distinction between objects and methods in this case:

• Objects that cannot be deserialise are not lost. They will instead be converted into a CustomObject. This means they will loose their type-strong nature but never their content. A message will explain to the user how to produce a type-strong objets from the CustomObject if at all possible.
• Methods are serialised when stored as component inside a script (or cell formula inside Excel). If deserialisation fails, the component will not disappear nor loose its' inputs/outputs. It will simply not return a valid output and instead display an error message explaining why it is not working and what action is required to make the script functional again.

Objects/methods deleted or without upgrades will generally be items created at the very early stages of a toolkit. Once the toolkit has gone through a few cycles of development, it is very unlikely that its objects will be modified or removed without versioning. Methods take a bit longer to stabilise but the same rule applies to them. We are using the BHoM on commercial projects that can be active or need update for years. So rest assure that backward compatibility is a key requirement for us too.

It is probably also worth mentioning that we actively working on better exposing to the user the level of maturity of an object/method to make it easier to decide if it can be safely used on project. See an initial example of development here: BHoM/Grasshopper_UI#634

[parched]

Ok, thanks, that's good to know. We only really care about the objects in this core repo, so changes in the toolkits don't bother us.