[Feature Request]: Add possibility to migrate between OASF versions

[lgecse]

This is a discussion starter only at the moment, please feel free to add your comments about the proposal.

Problem Statement

As a developer I don't have any automated way to migrate from an earlier version of OASF record to a newer version.

Proposed Solution

Provide migration capability between OASF record versions in the SDK.

Alternatives Considered

No response

Additional Context

No response

Checklist

• I have read the contributing guidelines
• I have verified this does not duplicate an existing feature request

[ramizpolic]

To add some context, on the Directory side we have managed to support multiple versions of OASF records to support the functionality provided by Dir. However, on other places like upstream users, this may still pose an issue.

On the dir-side we have opted in to have a multi-version support simply because of one thing: it is hard to guarantee that the migrations from one version to another are possible. However, so far, all the changes on the OASF record object schema were done in a way that the migration can be done (from v0.3 upto the latest one).

Therefore, if we want to support the migration, we should answer the following:

what happens when the migration is not possible? in other words, what options do I, as a developer, have to fix this problem?

IMO This can be sorted out on the SDK MigrationService level, such as

// grpc sample code to demonstrate the idea

service MigrationService {
	rpc MigrateToV2(v1) (v2)
	rpc MigrateToV3(v2, customMigrationOptions) (v3)
}

message customMigrationOptions {
	// some custom rules to apply when performing migration for an object
	// e.g. functional predicates, labels, etc
}

I am in favour of this since we can provide primitives to the developers to be able to bypass the cases when migration may not be possible. Happy to hear other opinions.

[outshift-jodeev]

Use cases? Some that I can think of:

• when an agentic resource is updated, this might aid in creating an updated record so that it conforms to the latest schema
• consumers (services?) may need to always use the latest schema, and so need a way to convert records

Alternatives:

• all records should have the OASF version (this is required) - so any consumers should be able to consume them "as is" by referring to the OASF schema version
• when an agentic resource is updated, then a new record is created from scratch using the latest schema rather than attempting to modify any existing records

Note that there are at least 2 consumers of OASF (front end GUI for directory, and a tool for creating records) facing this problem today and they need to be able to always keep up with the latest schema, so modifying records to always reflect the latest schema may not really help them.

If we believe that users will have tools to automatically construct records from them, and no records will be created manually, then we don't need a record version updater. (I don't believe this to be true yet - we don't provide any tools for automatic record creation at this time)

Are there other use cases?