@xen2 Shouldn’t the upgrade system not do/ask anything when only the minor/patch version has changed. I thought that we had that behaviour before.
Is it because of the project format change that it is not possible anymore? I would expect that projects created with version x.x.0.1 to keep targeting that version by default and still work if the binaries are swapped with x.x.1.2. Since minor/patch versions don’t introduce breaking changes.
NuGet PackageReference references an explicit version, and by default it takes the lowest matching version, so we have to update the project if we want a better patch update. (note: there might be a specific way to write the version with a range to circumvent that – would be fine to allow it if possible).
It was different before because projects were opened through Xenko and launcher which then force Xenko version in the project. Now it’s the other way around: a csproj references a Xenko version and it can trigger a Xenko runtime DL. Later we could extend the concept to get/launch proper Xenko editor automatically.
This is a change from the past, but I prefer the NuGet approach with an explicit version locked in.
Even if minor updates shouldn’t have any breaking changes, you sometimes don’t want surprise updates even if you have that newer Xenko version installed.
What I don’t like is that the message to upgrade appears for minor versions, which I find annoying. And if we refuse it keeps appearing next time the project is opened. There should be a way to only ask once for a minor version upgrade and remember the choice.
If you don’t want to upgrade project, it means you probably want to open project with older version of Xenko Editor maybe? (just a thought, not sure about that yet; also it’s not currently possible with current launcher)
Actually I was thinking longer term with #12 and #13, we’ll need to find a way to have the editor more flexible in the way it loads assemblies (editor resolve packages from game, and then loads the same dll). This could be one way to allow user to replace a few runtime dll with its own, etc…
Anyway, it’s going off topic, we should do this discussion either on github #12/#13 when I put the spec, or in another forum thread.