We are continuing design of the metadata update improvements, as discussed during the June sprint [1], and also related to previous discussion [2] and bugs [3][4][5].
Given that context, there are a few questions for which it would be nice to get some feedback before getting to work on a concrete plan:
After editing some fields in the UI, next uploads will be processed but warn about conflicts/not updating metadata? should some fields (the ones that weren’t changed in the UI) still be updated?
When updating metadata fields through snapcraft, we would only allow this by pushing snapcraft.yaml? Or there should be a command allowing to update any specific/editable field?
Where should license information come from? AFAICT there isn’t a license field in snapcraft.yaml, is it?
Note that besides license, there are other textual fields which can be updated in the web UI but for which there isn’t a snapcraft.yaml option, like changelog (per revision), price, support/contact URL.
Given that I wasn’t part of the sprint, I’ll try to answer with the best after the fact knowledge I have.
From what I recollect from conversations with @noise, @cprov and @niemeyer the ideal solution would be:
On snapcraft push if the metadata has changed, warn the user of conflicts (and show them), maybe even allow them to pull the metadata (to get the delta from the store).
On metadata update on the users side, the user can opt to send metadata through a new api and update all fields sent through there (including some newer ones currently not exposed such as screenshots).
License information will be validated on every aspect of the snappy ecosystem (snaps, snapcraft, store) with a a unique tool argument provided by the snap command or at least in snapcore/snapd, using a single tool has benefits. Once this is in place, we will enable the license field in snapcraft.yaml.
Metadata update shall not be automatic, it has to be user conscious choice.
I thought we planned to always attempt to update on push and the store would reply with warnings of conflicts but apply other changes that were not overridden in the store. There would be a separate command to force local changes to clobber the store data.
Now that you phrased it that way, you have jogged my memory and indeed it is what we decided. I am not sure however on how to determine when a conflict exists versus an update.
Note that, AFAIUI, we call it a conflict when you try to update a field via snapcraft that was previously edited in the web UI (ie. outside of the command line workflow). So, for example, if you always update metadata using snapcraft, you will never get a conflict.
If we check that the field changed in the portal and that the value you are pushing match the existing one, then we could let it pass (and update the server state on which fields are currently modified in the web UI). In that case, you are right, there won’t be a conflict later. But if the description doesn’t match, you will get a conflict at this point, and you won’t be able to update the metadata unless you explicitly force it.
