[FR] Add MLflow version to the MLModel spec

Thank you for submitting a feature request. Before proceeding, please review MLflow’s Issue Policy for feature requests and the MLflow Contributing Guide.

Please fill in this feature request template to ensure a timely and thorough response.

Willingness to contribute

The MLflow Community encourages new feature contributions. Would you or another member of your organization be willing to contribute an implementation of this feature (either as an MLflow Plugin or an enhancement to the MLflow code base)?

• Yes. I can contribute this feature independently.
• Yes. I would be willing to contribute this feature with guidance from the MLflow community.
• No. I cannot contribute this feature at this time.

Proposal Summary

Add an mlflow_version field to the MLModel spec that is automatically populated with the current MLflow version when an MLflow Model is saved / logged.

Motivation

• What is the use case for this feature? When saving an MLflow Model, it is helpful to know what version of MLflow was used to save the model for backwards compatibility & validation purposes.
• Why is this use case valuable to support for MLflow users in general? ^
• Why is this use case valuable to support for your project(s) or organization? ^
• Why is it currently difficult to achieve this use case? MLflow version information isn’t available anywhere in the serialized MLflow Model format.

What component(s), interfaces, languages, and integrations does this feature affect?

Components

• area/artifacts: Artifact stores and artifact logging
• area/build: Build and test infrastructure for MLflow
• area/docs: MLflow documentation pages
• area/examples: Example code
• area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry
• area/models: MLmodel format, model serialization/deserialization, flavors
• area/projects: MLproject format, project running backends
• area/scoring: MLflow Model server, model deployment tools, Spark UDFs
• area/server-infra: MLflow Tracking server backend
• area/tracking: Tracking Service, tracking client APIs, autologging

Interfaces

• area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev server
• area/docker: Docker use across MLflow’s components, such as MLflow Projects and MLflow Models
• area/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registry
• area/windows: Windows support

Languages

• language/r: R APIs and clients
• language/java: Java APIs and clients
• language/new: Proposals for new client languages

Integrations

• integrations/azure: Azure and Azure ML integrations
• integrations/sagemaker: SageMaker integrations
• integrations/databricks: Databricks integrations

Details

(Use this section to include any additional information about the feature. If you have a proposal for how to implement this feature, please include it here. For implementation guidelines, please refer to the Contributing Guide.)

[r3stl355]

I’ll pick this up

[andy1122]

Hey @andy1122 , I frankly don’t know what to say. I never collaborated with anyone in this type of setup. I prefer having my own pace for this type of work and don’t want to set any expectations/constraints or depend on others. This is a bite-size contribution so you can easily submit your own PR.

Hi @r3stl355, Okay you can goahead with this task. I will search for some other “good_first_issue”. Since i am new to this project, so i was looking to collaborate with others who are more experienced.