Version control

[RachL]

Here are my notes following discussions with @RaggedStaff @lecoqlibre @lin-d-hop and @simonLouvet - did I miss anything? Especially I think the part regarding the URL is wrong (I think in the last meeting we said we could just rely on the non mandatory fields like we did recently with logistics data - but I'm not 100% sure)

Context

Breaking changes have been introduced in the past without any good process to prevent them. And when we can't prevent them, we didn't give enough space to community members to fix their integration before the breaking change was released.

We want to change that, hence this discussion.

Issues we need to deal with

• we use an URL on the DFC website that changes, which then breaks everything 💥
• 2 platforms using 2 different versions: how can they continue to communicate together?

Agreed solutions

• In theory, from 1.8 onwards, we implemented only changes with “should” / optional stuff, so platforms can communicate with different version
• Idea for ontology documentation: split the ontology in several modules like “product”, “logistics” and say what should be implemented to support one module or another.
  Will these domains update ever introduce breaking changes? If we keep URL = 1 module, we should never encounter failure.
• If we need to introduce breaking changes, we need to have processes for notifying platforms. Platforms need to be able to subscribe to notifications.

Actions

• @RaggedStaff will draft a proposal for a notifications process (for breaking changes and release) for next tech meeting (February 26)
• we need to document this somewhere else than this discussion once we are clear :)

[RaggedStaff]

Idea for ontology documentation: split the ontology in several modules like “product”, “logistics” and say what should be implemented to support one module or another.
Will these domains update ever introduce breaking changes? If we keep URL = 1 module, we should never encounter failure.

I was a bit confused by this discussion on the call and I'm not sure we were all on the same page... I think there are 2 concepts here:

1. Splitting the ontology into "domains" (we're already partially done this with some additional Product details being included in a different owl file). Domains could look like: Agent, Product, Order etc... different areas of the ontology that we hold in separate owl files (& are pulled together in the Full ontology).
   This has advantages for working on the files - it makes them smaller & simpler. We can also confine changes to a single part of the ontology. It doesn't fix any Version Control issues.

2. The other concept (let's call that one "tiers" for now 😉) would be to have separate branches & releases for different milestones in the standards development/deployment. For example: Product, Orders & Logistics. That would mean we could stabilise the Product Tier, whilst still developing & releases (potentially breaking) changes to the Logistics Tier (as we advance our work with logistics partners).

I like the "tiers" concept, I thought that was what we were trying to discuss on the call & I'd like to explore what a branching strategy could look like to support that.

Would we have separate dev & release branches for each tier ? We could then apply (non-breaking) hotfixes across some or all tiers as we decide. It would incur additional overheads in maintaining the separate branches.

Another option would be forking the repository (so we have a separate forked repo for each tier, although I think that would make applying individual changes more difficult.

What do others think ?

[Alcoz]

At Elzeard, we chose to divide our ontology in multiple modules because it is easier to work on each subdomains when it is needed. I like this solution because it helps to clarify the ontology and work processes and I think it would be helpful to have the same for DFC ontology.

If I understand well, the "tiers" strategy implies to have multiple branches where we can work on each problem independently (Product, Orders, Logistics, etc.) but with the same base ontology version. If it is not that, I would need clarification. It is that, I wonder what happened if two branches go in two direction on the same concepts and how we manage that the day we want merge them. Ex: Logistics and Orders can have impact on Order concept.
I have an other question, do we still have a main ontology version and when do we choose to apply changes on this one.
Finally, what happened if a platform choose to use a tier branch instead of the main. The tiers branches must be regarded only as development branch and we prevent about that or it can seen as an "official" and possible conflict can be happened in future regarding the different branches.

Finally, both method can be implemented, first one for domain clarification and second one for versioning improvement. I'm not against the tier branch, any strategy is interesting and I'm clearly a beginner about versioning problem. I just have question regarding the implementation of the process and how we can do it properly to don't have too many branches and future conflicts.

[RaggedStaff]

Thanks for your comments @Alcoz

If I understand well, the "tiers" strategy implies to have multiple branches where we can work on each problem independently (Product, Orders, Logistics, etc.) but with the same base ontology version.

I think that's broadly correct. Although there may be differences: we may choose to only apply some fixes to earlier tiers, so the branches would "drift" out of alignment. We could rebase with each Major Version release to ensure ongoing conformity.

It may be unnecessary to do this, we may just be able to stick to (semantically) numbered versions and ensure platforms publish which version that are aligned too.

Wondering what others think @simonLouvet @lecoqlibre

[RaggedStaff]

At Elzeard, we chose to divide our ontology in multiple modules because it is easier to work on each subdomains when it is needed. I like this solution because it helps to clarify the ontology and work processes and I think it would be helpful to have the same for DFC ontology.

Do you have any thoughts/suggestions as to how we might split the ontology into modules/domains ?

[lecoqlibre]

From Florence on Slack:

One solution to this pb is to define a modular ontology, i.e. to define subgraphs that have the same perimeter and that can be linked one to another. That's what we did with the C3PO ontology https://www.elzeard.co/ontologies/c3po/ and is frequently implemented with large ontologies to ease their maintanability.

Each subgraphs define a coherent subdomain to represent. Regarding the DFC onto, it can be part of the processes for example.