Which versions of schemas are supported on which versions of GNS3?

[eantowne]

With 3.0 on the horizon, I was considering going through and updating appliances to newer schemas in order to support newer features provided in the latest schemas. However, I realized this may cause some serious issues. I would think that previous versions of GNS3 may not support the newest schema's if a user were to "Update from registry".

How should this be handled?

As an example, if I created an appliance that required TPM, and used schema v7 to provide that configuration item, what happens when a previous version of GNS3 tries to open that appliance template? I believe there have been issues already reported on GNS3.com for people who upgraded to 2.2.36, then had to downgrade and the "TPM" entry caused issues.

Does there need to be a property added to the schema's to specify GNS3 minimum version, then checks in the GUI/Server to deal with this?

At the very least, we may need a reference somewhere that details which GNS3 version was the starting point for each schema version.

[b-ehlers]

Does there need to be a property added to the schema's to specify GNS3 minimum version, then checks in the GUI/Server to deal with this?

The GNS3 GUI already checks the schema version in gns3/registry/appliance.py. If the schema of an appliance is not supported it shows the error "Please update GNS3 in order to install this appliance".

At the very least, we may need a reference somewhere that details which GNS3 version was the starting point for each schema version.

By checking the history of gns3/registry/appliance.py I compiled the following table:

Update: Added a column with features added to the scheme.

Schema	min. GNS3 version	Additions
2	1.4.0
3	1.5.0	docker
4	2.0.0	availability qemu/cpus qemu/hd?_disk_interface: sata versions/images/bios_image
5	2.1.0	qemu/console_type: spice
6	2.2.0	qemu/custom_adapters
7	2.2.36	qemu/tpm

[eantowne]

So, once an appliance is created, we should probably never upgrade the schema version in order to ensure backwards compatibility.

With a major version change such as 3.0, conceivably a new registry could be created with a new schema definition and all of the appliances could be updated. Might even be able to remove some REALLY old appliance versions as well removing any that may be broken or unmaintained, if no one wants to do the work to update them.

Sorry, I should have realized that appliance.py is checking these things. I would have been able to pull the versioning info, thanks for the reference!

[b-ehlers]

I have just added a column to my schema table. When we use schema 4 (compatible with GNS3 v2.0+) as the new default (currently it is 3), then only 6 appliances need a higher schema version, that's 3%. Using these 6 appliances in a GNS3 version, that lacks functionality needed for that appliance, will result in an error message. But I don't see, how this can be avoided.

[grossmj]

So, once an appliance is created, we should probably never upgrade the schema version in order to ensure backwards compatibility.

Basically yes, backwards compatibility is always an issue ;) As mentioned by @b-ehlers above, we could at least make schema 4 the new default as I don't think anyone uses GNS3 under version 2.0...

With a major version change such as 3.0, conceivably a new registry could be created with a new schema definition and all of the appliances could be updated. Might even be able to remove some REALLY old appliance versions as well removing any that may be broken or unmaintained, if no one wants to do the work to update them.

3.0 is the opportunity to make major changes like suggested in https://github.com/GNS3/gns3-registry/issues/726 and clean things out (more suggestions welcome!). I am also thinking about a new registry to start fresh with 3.0

@b-ehlers thanks for the schema table. I will use it to update the README.

[eantowne]

I like the idea of a new registry for 3.0, fresh start and all that. My concern would be the level of work involved. The GNS3.com Marketplace would need some changes to accompany as well.

[grossmj]

I like the idea of a new registry for 3.0, fresh start and all that. My concern would be the level of work involved. The GNS3.com Marketplace would need some changes to accompany as well.

I think it would be worth it. Let me check the lever of work involved.

[grossmj]

Please see https://github.com/GNS3/gns3-registry/discussions/729

[eantowne]

Discussion in #729 covers this issue, closing