### What needs to get done Currently, if a `snapcraft.yaml` for a `base: core20` snap defines both a `version|grade` as well as `adopt-info`, what is defined in `version|grade` are kept: > The 'grade' and 'version' properties are specified in adopted info as well as the YAML: taking the properties from the YAML However, if a snap defines both of these and for some reason the information is *not* set by that relevant part, an error instead occurs: > Failed to generate snap metadata: 'adopt-info' refers to part 'my-part', but that part is lacking the 'parse-info' property. Given the current, behavior, I would expect a warning or a message not a failure, as the information is going to be overridden anways. I suggest: if `adopt-info` is specified and the version or grade are set in the specified part, that information should take precedent over what is set in the YAML, and if it isn't set in that part then the snap should defer to the specified `version|grade` in the YAML. ### Why it needs to get done Aside from conforming to a general UNIX-y order of precendence (invocation > user > global) where specifying e.g. a command-line flag will override an environment variable that is set, it would also be nice to have some sort of check in a part which dynamically changes the version string based on the state of the source or how the build went. For instance, it may be the case that I want the version of my snap to be `version: 11` but I set up some logic in my build system which, if some fact obtains, ACTUALLY the version and grade are changed to `11-dev` and `devel` respectively. Now I can't erroneously push what was in FACT a binary built from development-grade source to `latest/stable`, and that this snap is a dev snap is very obvious from inspecting the version string (I no longer have to refer to the source).