Manifest: Permit name change (as well as other meta-datas) #111

New Issue

Dalai Felinto · 2024-05-03T19:21:17+02:00

Dalai Felinto commented

2024-05-03 19:21:17 +02:00

At the moment is not possible to update the name of an extension by uploading a new version.

The only fields that can never change are:
* id
* type

This was discussed in this meeting but I forgot to create a task for that.

At the moment is not possible to update the name of an extension by uploading a new version. The only fields that can never change are: * id * type This was discussed in [this meeting](https://devtalk.blender.org/t/2024-04-16-extensions-platform-backend/34247#topics-3) but I forgot to create a task for that.

Oleg-Komarov commented

2024-05-06 12:03:33 +02:00

see also #60
maybe makes sense to unite into a single issue

see also #60 maybe makes sense to unite into a single issue

Dalai Felinto commented

2024-05-06 12:33:23 +02:00

@Oleg-Komarov I will close #60. In this case do you mind if I fix this one case on the database? Or were you planning to do a migration?

Oleg-Komarov commented

2024-05-06 12:37:16 +02:00

Yes, we can close that one as a duplicate.
If we need we can also do a batch run for all latest versions to update all metadata across the site.

Yes, we can close that one as a duplicate. If we need we can also do a batch run for all latest versions to update all metadata across the site.

Dalai Felinto commented

2024-05-06 12:45:50 +02:00

Ok will close it, for own records, this extension also needs latest info https://extensions.blender.org/approval-queue/dragengine-tools/.

Dalai Felinto referenced this issue

2024-05-06 12:46:46 +02:00

Blender Extensions don't update website on new menifest version update #60

Oleg-Komarov self-assigned this 2024-05-06 18:01:44 +02:00

Oleg-Komarov commented

2024-05-07 10:04:08 +02:00

I think that for completeness it's better to extend the logic in this way:
when a list of extension versions changes, i.e. either a new version is uploaded or some version gets deleted, we recalculate the updatable fields from the latest version manifest.

This will prevent situations when (so far only in draft) a user deletes a version, but the extension fields keep the values defined in a manifest of a no longer existing version.

I think that for completeness it's better to extend the logic in this way: when a list of extension versions changes, i.e. either a new version is uploaded or some version gets deleted, we recalculate the updatable fields from the latest version manifest. This will prevent situations when (so far only in draft) a user deletes a version, but the extension fields keep the values defined in a manifest of a no longer existing version.

Dalai Felinto commented

2024-05-07 10:41:28 +02:00

@Oleg-Komarov I think that's fine.

A potential future problem (of storing this at extension at all) is that on the extension listing we may not share the latest extension (given the blender_version_max). In this case we need to make sure we are passing the info from the corresponding manifest, instead of the extension itself.

For instance, the code in extensions/views/api.py right now does: 'name': instance.name, instead of something like `matching_version.name or matching_version.metatadata['name'].

@Oleg-Komarov I think that's fine. A potential future problem (of storing this at extension at all) is that on the extension listing we may not share the latest extension (given the blender_version_max). In this case we need to make sure we are passing the info from the corresponding manifest, instead of the extension itself. For instance, the code in extensions/views/api.py right now does: `'name': instance.name`, instead of something like `matching_version.name or matching_version.metatadata['name'].

Oleg-Komarov commented

2024-05-07 10:50:11 +02:00

That's a good point.
Now that I think of it, the fields that we need to update (name, support, website) are not version-specific at all. Why not add them to extension form and let the maintainers just edit them when they need it?

We could either accept a potential discrepancy with manifest fields or make it a part of manifest validation: old versions are kept as is, but uploading a new version will require a user to make sure that the manifest content matches the state of the extension object.

That's a good point. Now that I think of it, the fields that we need to update (name, support, website) are not version-specific at all. Why not add them to extension form and let the maintainers just edit them when they need it? We could either accept a potential discrepancy with manifest fields or make it a part of manifest validation: old versions are kept as is, but uploading a new version will require a user to make sure that the manifest content matches the state of the extension object.

Dalai Felinto commented

2024-05-07 11:53:40 +02:00

I would rather we stick to the manifest as the ground-truth for this. A name is no different than a Tag, or the Tagline. If users want to change that they send a new version.

Oleg-Komarov referenced this issue from a commit

2024-05-10 13:35:00 +02:00

Update extension fields from manifest metadata #111

Oleg-Komarov referenced this issue

2024-05-10 13:35:29 +02:00

Update extension fields from manifest metadata #111 #121

Oleg-Komarov referenced this issue from a commit

2024-05-10 15:13:33 +02:00

Update extension fields from manifest metadata #111 (#121)

Oleg-Komarov commented

2024-05-10 15:33:02 +02:00

Deployed in production.